This typically is only for a new enough linker (bfd >= 2.16.2 or gold), but
our ppc suppport post-dates this and it should work on all linux platforms. It
is guaranteed to work on all elfv2 platforms.
llvm-svn: 298765
and into TargetInfo::adjust so that it gets called in more places
throughout the compiler (AST serialization in particular).
Should fix PPC modules after removing of faltivec.
llvm-svn: 298487
The alias was only ever used on darwin and had some issues there,
and isn't used in practice much. Also fixes a problem with -mno-altivec
not turning off -maltivec.
Also add a diagnostic for faltivec/fno-altivec that directs users to use
maltivec options and include the altivec.h file explicitly.
llvm-svn: 298449
This reverts commit r298185, effectively reapplying r298165, after fixing the
new unit tests (PR32338). The memory buffer generator doesn't null-terminate
the MemoryBuffer it creates; this version of the commit informs getMemBuffer
about that to avoid the assert.
Original commit message follows:
----
Clang's internal build system for implicit modules uses lock files to
ensure that after a process writes a PCM it will read the same one back
in (without contention from other -cc1 commands). Since PCMs are read
from disk repeatedly while invalidating, building, and importing, the
lock is not released quickly. Furthermore, the LockFileManager is not
robust in every environment. Other -cc1 commands can stall until
timeout (after about eight minutes).
This commit changes the lock file from being necessary for correctness
to a (possibly dubious) performance hack. The remaining benefit is to
reduce duplicate work in competing -cc1 commands which depend on the
same module. Follow-up commits will change the internal build system to
continue after a timeout, and reduce the timeout. Perhaps we should
reconsider blocking at all.
This also fixes a use-after-free, when one part of a compilation
validates a PCM and starts using it, and another tries to swap out the
PCM for something new.
The PCMCache is a new type called MemoryBufferCache, which saves memory
buffers based on their filename. Its ownership is shared by the
CompilerInstance and ModuleManager.
- The ModuleManager stores PCMs there that it loads from disk, never
touching the disk if the cache is hot.
- When modules fail to validate, they're removed from the cache.
- When a CompilerInstance is spawned to build a new module, each
already-loaded PCM is assumed to be valid, and is frozen to avoid
the use-after-free.
- Any newly-built module is written directly to the cache to avoid the
round-trip to the filesystem, making lock files unnecessary for
correctness.
Original patch by Manman Ren; most testcases by Adrian Prantl!
llvm-svn: 298278
Clang's internal build system for implicit modules uses lock files to
ensure that after a process writes a PCM it will read the same one back
in (without contention from other -cc1 commands). Since PCMs are read
from disk repeatedly while invalidating, building, and importing, the
lock is not released quickly. Furthermore, the LockFileManager is not
robust in every environment. Other -cc1 commands can stall until
timeout (after about eight minutes).
This commit changes the lock file from being necessary for correctness
to a (possibly dubious) performance hack. The remaining benefit is to
reduce duplicate work in competing -cc1 commands which depend on the
same module. Follow-up commits will change the internal build system to
continue after a timeout, and reduce the timeout. Perhaps we should
reconsider blocking at all.
This also fixes a use-after-free, when one part of a compilation
validates a PCM and starts using it, and another tries to swap out the
PCM for something new.
The PCMCache is a new type called MemoryBufferCache, which saves memory
buffers based on their filename. Its ownership is shared by the
CompilerInstance and ModuleManager.
- The ModuleManager stores PCMs there that it loads from disk, never
touching the disk if the cache is hot.
- When modules fail to validate, they're removed from the cache.
- When a CompilerInstance is spawned to build a new module, each
already-loaded PCM is assumed to be valid, and is frozen to avoid
the use-after-free.
- Any newly-built module is written directly to the cache to avoid the
round-trip to the filesystem, making lock files unnecessary for
correctness.
Original patch by Manman Ren; most testcases by Adrian Prantl!
llvm-svn: 298165
Modified the tests to accept any iteration order, to run only on Unix, and added
additional error reporting to investigate SystemZ bot issue.
The VFS directory iterator and recursive directory iterator behave differently
from the LLVM counterparts. Once the VFS iterators hit a broken symlink they
immediately abort. The LLVM counterparts don't stat entries unless they have to
descend into the next directory, which allows to recover from this issue by
clearing the error code and skipping to the next entry.
This change adds similar behavior to the VFS iterators. There should be no
change in current behavior in the current CLANG source base, because all
clients have loop exit conditions that also check the error code.
This fixes rdar://problem/30934619.
Differential Revision: https://reviews.llvm.org/D30768
llvm-svn: 297693
We can't actually pretend that 0 is valid for address space 0.
r295877 added a workaround to stop allocating user objects
there, so we can use 0 as the invalid pointer.
Some of the tests seemed to be using private as the non-0 null
test address space, so add copies using local to make sure
this is still stressed.
llvm-svn: 297659
Change ASTFileSignature from a random 32-bit number to the hash of the
PCM content.
- Move definition ASTFileSignature to Basic/Module.h so Module and
ASTSourceDescriptor can use it.
- Change the signature from uint64_t to std::array<uint32_t,5>.
- Stop using (saving/reading) the size and modification time of PCM
files when there is a valid SIGNATURE.
- Add UNHASHED_CONTROL_BLOCK, and use it to store the SIGNATURE record
and other records that shouldn't affect the hash. Because implicit
modules reuses the same file for multiple levels of -Werror, this
includes DIAGNOSTIC_OPTIONS and DIAG_PRAGMA_MAPPINGS.
This helps to solve a PCH + implicit Modules dependency issue: PCH files
are handled by the external build system, whereas implicit modules are
handled by internal compiler build system. This prevents invalidating a
PCH when the compiler overwrites a PCM file with the same content
(modulo the diagnostic differences).
Design and original patch by Manman Ren!
llvm-svn: 297655
Modified the tests to accept any iteration order.
The VFS directory iterator and recursive directory iterator behave differently
from the LLVM counterparts. Once the VFS iterators hit a broken symlink they
immediately abort. The LLVM counterparts allow to recover from this issue by
clearing the error code and skipping to the next entry.
This change adds the same functionality to the VFS iterators. There should be
no change in current behavior in the current CLANG source base, because all
clients have loop exit conditions that also check the error code.
This fixes rdar://problem/30934619.
Differential Revision: https://reviews.llvm.org/D30768
llvm-svn: 297528
The VFS directory iterator and recursive directory iterator behave differently
from the LLVM counterparts. Once the VFS iterators hit a broken symlink they
immediately abort. The LLVM counterparts allow to recover from this issue by
clearing the error code and skipping to the next entry.
This change adds the same functionality to the VFS iterators. There should be
no change in current behavior in the current CLANG source base, because all
clients have loop exit conditions that also check the error code.
This fixes rdar://problem/30934619.
Differential Revision: https://reviews.llvm.org/D30768
llvm-svn: 297510
that return record or vector types
The performSelector family of methods from Foundation use objc_msgSend to
dispatch the selector invocations to objects. However, method calls to methods
that return record types might have to use the objc_msgSend_stret as the return
value won't find into the register. This is also supported by this sentence from
performSelector documentation: "The method should not have a significant return
value and should take a single argument of type id, or no arguments". This
commit adds a new warning that warns when a selector which corresponds to a
method that returns a record type is passed into performSelector.
rdar://12056271
Differential Revision: https://reviews.llvm.org/D30174
llvm-svn: 297019
Summary:
Historically, NetBSD, FreeBSD and OpenBSD have defined the macro ABICALLS in
the preprocessor when -mabicalls is in effect.
Mainline GCC later defined __mips_abicalls when -mabicalls is in effect.
This patch teaches the preprocessor to define these macros when appropriate.
NetBSD does not require the ABICALLS macro.
This resolves PR/31694.
Thanks to Sean Bruno for highlighting this issue!
Reviewers: slthakur, seanbruno
Reviewed By: seanbruno
Subscribers: joerg, brad, emaste, seanbruno, cfe-commits
Differential Revision: https://reviews.llvm.org/D29032
llvm-svn: 295728
https://reviews.llvm.org/D29922
This patch adds two fields for use in the implementation of 'distribute parallel for':
The increment expression for the distribute loop. As the chunk assigned to a team is executed by multiple threads within the 'parallel for' region, the increment expression has to correspond to the value returned by the related runtime call (for_static_init).
The upper bound of the innermost loop ('for' in 'distribute parallel for') is not the globalUB expression normally used for pragma 'for' when found in isolation. It is instead the upper bound of the chunk assigned to the team ('distribute' loop). In this way, we prevent teams from executing chunks assigned to other teams.
The use of these two fields can be see in a related explanatory patch:
https://reviews.llvm.org/D29508
llvm-svn: 295497
Summary:
The -mmcu option for GCC sets macros like __AVR_ATmega328P__ (with the trailing
underscores), be sure to include these underscores for Clangs -mcpu option.
See "AVR Built-in Macros" in https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html
Reviewers: jroelofs, dylanmckay
Reviewed By: jroelofs, dylanmckay
Subscribers: efriedma, cfe-commits
Differential Revision: https://reviews.llvm.org/D29817
llvm-svn: 294869
until we can get better TargetMachine::isCompatibleDataLayout to compare - otherwise
we can't code generate existing bitcode without a string equality data layout.
This reverts commit r294703.
llvm-svn: 294708
For other platforms we should find out what they need and likely
make the same change, however, a smaller additional change is easier
for platforms we know have it specified in the ABI.
clang support for r294702
llvm-svn: 294703
This is a followup change to add v7ve support to clang for gcc
compatibility. Please see r294661.
Patch by Manoj Gupta.
Differential Revision: https://reviews.llvm.org/D29773
llvm-svn: 294662
1. Adds the command line flag for clzero.
2. Includes the clzero flag under znver1.
3. Defines the macro for clzero.
4. Adds a new file which has the intrinsic definition for clzero instruction.
Patch by Ganesh Gopalasubramanian with some additional tests from me.
Differential revision: https://reviews.llvm.org/D29386
llvm-svn: 294559
This feature flag indicates that the processor has support for removing certain instructions from user mode software. But the feature flag by itself doesn't indicate if the support is enabled in the OS. The affected instructions aren't even instructions the compiler would emit. So I don't think think this feature flag should be in the compiler.
llvm-svn: 294414
GCC 7 will predefine two new macros on s390x:
- __ARCH__ indicates the ISA architecture level
- __VX__ indicates that the vector facility is available
This adds those macros to clang as well to ensure continued
compatibility with GCC.
llvm-svn: 294197
Summary:
This tells clang about all of the different AVR microcontrollers.
It also adds code to define the correct preprocessor macros for each
device.
Reviewers: jroelofs, asl
Reviewed By: asl
Subscribers: asl, cfe-commits
Differential Revision: https://reviews.llvm.org/D28346
llvm-svn: 294177
Summary:
Previously the method would simply return false, causing every single
inline assembly constraint to trigger a compile error.
This adds inline assembly constraint support for the AVR target.
This patch is derived from the code in
AVRISelLowering::getConstraintType.
More details can be found on the AVR-GCC reference wiki
http://www.nongnu.org/avr-libc/user-manual/inline_asm.html
Reviewers: jroelofs, asl
Reviewed By: asl
Subscribers: asl, ahatanak, saaadhu, cfe-commits
Differential Revision: https://reviews.llvm.org/D28344
llvm-svn: 294176
GCC does not generate `__unix` nor `unix` macros. The latter already
intrudes into the user's namespace and should be avoided. Use the
canonical spelling of `__unix__` across all the targets.
llvm-svn: 294148
First pass at generating weak definitions of inline functions from module files
(& skipping (-O0) or emitting available_externally (optimizations)
definitions where those modules are used).
External functions defined in modules are emitted into the modular
object file as well (this may turn an existing ODR violation (if that
module were imported into multiple translations) into valid/linkable
code).
Internal symbols (static functions, for example) are not correctly
supported yet. The symbol will be produced, internal, in the modular
object - unreferenceable from the users.
Reviewers: rsmith
Differential Revision: https://reviews.llvm.org/D28845
llvm-svn: 293456
Rather than storing a single flat list of SourceLocations where the diagnostic
state changes (in source order), we now store a separate list for each FileID
in which there is a diagnostic state transition. (State for other files is
built and cached lazily, on demand.) This has two consequences:
1) We can now sensibly support modules, and properly track the diagnostic state
for modular headers (this matters when, for instance, triggering instantiation
of a template defined within a module triggers diagnostics).
2) It's much faster than the old approach, since we can now just do a binary
search on the offsets within the FileID rather than needing to call
isBeforeInTranslationUnit to determine source order (which is surprisingly
slow). For some pathological (but real world) files, this reduces total
compilation time by more than 10%.
For now, the diagnostic state points for modules are loaded eagerly. It seems
feasible to defer this until diagnostic state information for one of the
module's files is needed, but that's not part of this patch.
llvm-svn: 293123
This patch adds support for codegen of 'target teams' on the host.
This combined directive has two captured statements, one for the
'teams' region, and the other for the 'parallel'.
This target teams region is offloaded using the __tgt_target_teams()
call. The patch sets the number of teams as an argument to
this call.
Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D29084
llvm-svn: 293005
This patch adds support for codegen of 'target teams' on the host.
This combined directive has two captured statements, one for the
'teams' region, and the other for the 'parallel'.
This target teams region is offloaded using the __tgt_target_teams()
call. The patch sets the number of teams as an argument to
this call.
Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D29084
llvm-svn: 293001
This patch adds support for codegen of 'target parallel' on the host.
It is also the first combined directive that requires two or more
captured statements. Support for this functionality is included in
the patch.
A combined directive such as 'target parallel' has two captured
statements, one for the 'target' and the other for the 'parallel'
region. Two captured statements are required because each has
different implicit parameters (see SemaOpenMP.cpp). For example,
the 'parallel' has 'global_tid' and 'bound_tid' while the 'target'
does not. The patch adds support for handling multiple captured
statements based on the combined directive.
When codegen'ing the 'target parallel' directive, the 'target'
outlined function is created using the outer captured statement
and the 'parallel' outlined function is created using the inner
captured statement.
Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D28753
llvm-svn: 292419
This is just wasted space, we don't support state points from multiple
source managers. Validate that there's no state when resetting the
source manager and use the 'global' reference to the sourcemanager
instead of the ones in the diag state.
llvm-svn: 292402
This patch adds support for codegen of 'target parallel' on the host.
It is also the first combined directive that requires two or more
captured statements. Support for this functionality is included in
the patch.
A combined directive such as 'target parallel' has two captured
statements, one for the 'target' and the other for the 'parallel'
region. Two captured statements are required because each has
different implicit parameters (see SemaOpenMP.cpp). For example,
the 'parallel' has 'global_tid' and 'bound_tid' while the 'target'
does not. The patch adds support for handling multiple captured
statements based on the combined directive.
When codegen'ing the 'target parallel' directive, the 'target'
outlined function is created using the outer captured statement
and the 'parallel' outlined function is created using the inner
captured statement.
Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D28753
llvm-svn: 292374
This patch is to implement sema and parsing for 'target teams distribute simd’ pragma.
Differential Revision: https://reviews.llvm.org/D28252
llvm-svn: 291579
Summary:
This patch enables the following
1. AMD family 17h architecture using "znver1" tune flag (-march, -mcpu).
2. ISAs that are enabled for "znver1" architecture.
3. Checks ADX isa from cpuid to identify "znver1" flag when -march=native is used.
4. ISAs FMA4, XOP are disabled as they are dropped from amdfam17.
5. For the time being, it uses the btver2 scheduler model.
6. Test file is updated to check this flag.
This is linked to llvm review item https://reviews.llvm.org/D28017
Patch by Ganesh Gopalasubramanian. Additional test cases added by Craig Topper.
Reviewers: RKSimon, craig.topper
Subscribers: cfe-commits, RKSimon, ashutosh.nema, llvm-commits
Differential Revision: https://reviews.llvm.org/D28018
llvm-svn: 291544
Summary:
When compiling device code, we may still see host code with explicit
calling conventions. NVPTX needs to claim that it supports these CCs,
so that (a) we don't raise noisy warnings, and (b) we don't break
existing code which relies on the existence of these CCs when
specializing templates. (If a CC doesn't exist, clang ignores it, so
two template specializations which are different only insofar as one
specifies a CC are considered identical and therefore are an error if
that CC is not supported.)
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28323
llvm-svn: 291136
Summary:
CUDA lets users share structs between the host and device, so for that
and other reasons, primitive types such as ptrdiff_t should be the same
on both sides of the compilation.
Our code to do this wasn't entirely successful. In particular, we did a
bunch of work during the NVPTXTargetInfo constructor, only to override
it in the NVPTX{32,64}TargetInfo constructors. It worked well enough on
Linux and Mac, but Windows is LLP64, which is different enough to break
it.
This patch removes the NVPTX{32,64}TargetInfo classes entirely and fixes
the bug described above.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28322
llvm-svn: 291135
Summary:
Authored by Senthil Kumar Selvaraj
This patch adds barebones support in Clang for the (experimental) AVR target. It uses the integrated assembler for assembly, and the GNU linker for linking, as lld doesn't know about the target yet.
The DataLayout string is the same as the one in AVRTargetMachine.cpp. The alignment specs look wrong to me, as it's an 8 bit target and all types only need 8 bit alignment. Clang failed with a datalayout mismatch error when I tried to change it, so I left it that way for now.
Reviewers: rsmith, dylanmckay, cfe-commits, rengolin
Subscribers: rengolin, jroelofs, wdng
Differential Revision: https://reviews.llvm.org/D27123
llvm-svn: 291082
This patch is to implement sema and parsing for 'target teams distribute parallel for simd’ pragma.
Differential Revision: https://reviews.llvm.org/D28202
llvm-svn: 290862
This patch is to implement sema and parsing for 'target teams distribute parallel for’ pragma.
Differential Revision: https://reviews.llvm.org/D28160
llvm-svn: 290725
According to extended asm syntax, a case where the clobber list includes a variable from the inputs or outputs should be an error - conflict.
for example:
const long double a = 0.0;
int main()
{
char b;
double t1 = a;
__asm__ ("fucompp": "=a" (b) : "u" (t1), "t" (t1) : "cc", "st", "st(1)");
return 0;
}
This should conflict with the output - t1 which is st, and st which is st aswell.
The patch fixes it.
Commit on behald of Ziv Izhar.
Differential Revision: https://reviews.llvm.org/D15075
llvm-svn: 290539
This patch is to implement sema and parsing for 'target teams distribute' pragma.
Differential Revision: https://reviews.llvm.org/D28015
llvm-svn: 290508
diagnostics and fix one such diagnostic.
Sadly, this assert doesn't catch this bug because we have no tests that
emit this diagnostic! Doh! I'm following up on the commit that
introduces it to get that fixed. Then this assert will help in a more
direct way.
llvm-svn: 290417
Merge all VFS mapped files inside -ivfsoverlay inputs into the vfs
overlay provided by the crash reproducer. This is the last missing piece
to allow crash reproducers to fully work with user frameworks; when
combined with headermaps, it allows clang to find additional frameworks.
rdar://problem/27913709
llvm-svn: 290326
Added a map to associate types and declarations with extensions.
Refactored existing diagnostic for disabled types associated with extensions and extended it to declarations for generic situation.
Fixed some bugs for types associated with extensions.
Allow users to use pragma to declare types and functions for supported extensions, e.g.
#pragma OPENCL EXTENSION the_new_extension_name : begin
// declare types and functions associated with the extension here
#pragma OPENCL EXTENSION the_new_extension_name : end
Differential Revision: https://reviews.llvm.org/D21698
llvm-svn: 289979
At least the plugin used by the LibreOffice build
(<https://wiki.documentfoundation.org/Development/Clang_plugins>) indirectly
uses those members (through inline functions in LLVM/Clang include files in turn
using them), but they are not exported by utils/extract_symbols.py on Windows,
and accessing data across DLL/EXE boundaries on Windows is generally
problematic.
Differential Revision: https://reviews.llvm.org/D26671
llvm-svn: 289647
In amdgcn target, null pointers in global, constant, and generic address space take value 0 but null pointers in private and local address space take value -1. Currently LLVM assumes all null pointers take value 0, which results in incorrectly translated IR. To workaround this issue, instead of emit null pointers in local and private address space, a null pointer in generic address space is emitted and casted to local and private address space.
Tentative definition of global variables with non-zero initializer will have weak linkage instead of common linkage since common linkage requires zero initializer and does not have explicit section to hold the non-zero value.
Virtual member functions getNullPointer and performAddrSpaceCast are added to TargetCodeGenInfo which by default returns ConstantPointerNull and emitting addrspacecast instruction. A virtual member function getNullPointerValue is added to TargetInfo which by default returns 0. Each target can override these virtual functions to get target specific null pointer and the null pointer value for specific address space, and perform specific translations for addrspacecast.
Wrapper functions getNullPointer is added to CodegenModule and getTargetNullPointerValue is added to ASTContext to facilitate getting the target specific null pointers and their values.
This change has no effect on other targets except amdgcn target. Other targets can provide support of non-zero null pointer in a similar way.
This change only provides support for non-zero null pointer for C and OpenCL. Supporting for other languages will be added later incrementally.
Differential Revision: https://reviews.llvm.org/D26196
llvm-svn: 289252
This patch is to implement sema and parsing for 'teams distribute parallel for' pragma.
Differential Revision: https://reviews.llvm.org/D27345
llvm-svn: 289179
Revert r288447 which introduced -mdirect. It turns out we don't need a
custom flag for this, as the information we need is in the target triple.
llvm-svn: 288604
This patch is to implement sema and parsing for 'teams distribute parallel for simd' pragma.
Differential Revision: https://reviews.llvm.org/D27084
llvm-svn: 288294
Summary:
This macro should be defined only when the user directly specifies an
API level as part of an Android target. For any regular Android target,
we leave this macro undefined.
Bug: https://llvm.org/bugs/show_bug.cgi?id=30940
Reviewers: eugenis, pirama
Subscribers: tberghammer, cfe-commits, pirama, eugenis, danalbert
Differential Revision: https://reviews.llvm.org/D26491
llvm-svn: 286543
Summary: This is needed to make the v64i8 and v32i16 types legal for the 512-bit VBMI instructions. Fixes PR30912.
Reviewers: delena, zvi
Subscribers: RKSimon, cfe-commits
Differential Revision: https://reviews.llvm.org/D26306
llvm-svn: 286340
Summary:
Bug: https://llvm.org/bugs/show_bug.cgi?id=30940
This macro (along with __ANDROID__) should always be defined for Android
targets. We set it to the major (only) version of the Android API being
compiled for. The Android version is able to be set as an integer suffix
for any valid Android target.
Reviewers: danalbert, eugenis
Subscribers: cfe-commits, pirama, eugenis, tberghammer, danalbert
Differential Revision: https://reviews.llvm.org/D26385
llvm-svn: 286295
which guarantee pointers are not null. These all seem to have useful
properties and correlations to document, in one case we even had it in
a comment but now it will also be an assert.
This should prevent PVS-Studio from incorrectly claiming that there are
a bunch of potential bugs here. But I feel really strongly that the
PVS-Studio warnings that pointed at this code have a far too high
false-positive rate to be entirely useful. These are just places where
there did seem to be a useful invariant to document and verify with an
assert. Several other places in the code were already correct and
already have perfectly clear code documenting and validating their
invariants, but still ran afoul of PVS-Studio.
llvm-svn: 285985
This patch implements the register call calling convention, which ensures
as many values as possible are passed in registers. CodeGen changes
were committed in https://reviews.llvm.org/rL284108.
Differential Revision: https://reviews.llvm.org/D25204
llvm-svn: 285849
Summary:
This patch adds a command line option '-cl-ext' to control a set of
supported OpenCL extensions. Option accepts a comma-separated list
of extensions prefixed with '+' or '-'.
It can be used together with a target triple to override support for some
extensions:
// spir target supports all extensions, but we want to disable fp64
clang -cc1 -triple spir-unknown-unknown -cl-ext=-cl_khr_fp64
Special 'all' extension allows to enable or disable all possible
extensions:
// only fp64 will be supported
clang -cc1 -triple spir-unknown-unknown -cl-ext=-all,+cl_khr_fp64
Patch by asavonic (Andrew Savonichev).
Reviewers: joey, yaxunl
Subscribers: yaxunl, bader, Anastasia, cfe-commits
Differential Revision: https://reviews.llvm.org/D23712
llvm-svn: 285700
Commit on behalf of: Coby Tayree
1.'v' constraint for (x86) non-avx arch imitates the already implemented 'x' constraint, i.e. allows XMM{0-15} & YMM{0-15} depending on the apparent arch & mode (32/64).
2.for the avx512 arch it allows [X,Y,Z]MM{0-31} (mode dependent)
This patch applies the needed changes to clang
LLVM patch: https://reviews.llvm.org/D25005
Differential Revision: https://reviews.llvm.org/D25005
llvm-svn: 285688
Commit on behalf of mharoush
Extending inline assembly support, compatible with GCC as folowing:
"k" constraint hints the compiler to select any of AVX512 k0-k7 registers.
"Yk" constraint is a subset of "k" excluding k0 which is not allowd to be used as a mask.
Reviewer: 1. rnk
Differential Revision: https://reviews.llvm.org/D25063
llvm-svn: 285604
For compatibility with other compilers on the platform, allow specifying
levels of the z/Architecture instead of model names with -march. In
particular, the following aliases are now supported:
-march=arch8 equals -march=z10
-march=arch9 equals -march=z196
-march=arch10 equals -march=zEC12
-march=arch11 equals -march=z13
This parallels the equivalent (and prerequisite) LLVM change in r285577.
llvm-svn: 285578
Commit on behalf of mharoush
After LGTM and check all:
This patch enables usage of k registers in inline assembly syntax.
Adding triple
Reviewer: 1. rnk
2. delena
Differential Revision: https://reviews.llvm.org/D25011
llvm-svn: 285563
Commit on behalf of mharoush
After LGTM and check all:
This patch enables usage of k registers in inline assembly syntax.
Reviewer: 1. rnk
2. delena
Differential Revision: https://reviews.llvm.org/D25011
llvm-svn: 285555
r276653 suppressed the pragma once warning when generating a PCH file.
This patch extends that to any main file for which clang is told (with
the -x option) that it's a header file. It will also suppress the
warning "#include_next in primary source file".
Differential Revision: http://reviews.llvm.org/D25989
llvm-svn: 285295
Fuchsia has experimental support for 32-bit x86 and ARM targets, add
them to the list of supported targets.
Differential Revision: https://reviews.llvm.org/D25838
llvm-svn: 285038
The 'no_undeclared_includes' attribute should be used in a module to
tell that only non-modular headers and headers from used modules are
accepted.
The main motivation behind this is to prevent dep cycles between system
libraries (such as darwin) and libc++.
Patch by Richard Smith!
llvm-svn: 284797
Use the LLVM_CMAKE_PATH variable to locate the GetSVN.cmake script.
The variable was already available in stand-alone builds, and is also
set by LLVM since r284581.
llvm-svn: 284582
Summary: _BitScan intrinsics (and some others, for example _Interlocked and _bittest) are supposed to work on both ARM and x86. This is an attempt to isolate them, avoiding repeating their code or writing separate function for each builtin.
Reviewers: hans, thakis, rnk, majnemer
Subscribers: RKSimon, cfe-commits, aemerson
Differential Revision: https://reviews.llvm.org/D25264
llvm-svn: 284060
Commit in the name of: Coby Tayree
1.'v' constraint for (x86) non-avx arch imitates the already implemented 'x' constraint, i.e. allows XMM{0-15} & YMM{0-15} depending on the apparent arch & mode (32/64).
2.for the avx512 arch it allows [X,Y,Z]MM{0-31} (mode dependent)
This patch applies the needed changes to clang
LLVM patch: https://reviews.llvm.org/D25005
Differential Revision: D25004
llvm-svn: 283716
Provide toolchain and tool support for Fuchsia operating system.
Fuchsia uses compiler-rt as the runtime library and libc++, libc++abi
and libunwind as the C++ standard library. lld is used as a default
linker.
Differential Revision: https://reviews.llvm.org/D25117
llvm-svn: 283420
Summary: We need x86-64-specific builtins if we want to implement some of the MS intrinsics - winnt.h contains definitions of some functions for i386, but not for x86-64 (for example _InterlockedOr64), which means that we cannot treat them as builtins for both i386 and x86-64, because then we have definitions of builtin functions in winnt.h on i386.
Reviewers: thakis, majnemer, hans, rnk
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24598
llvm-svn: 283264
Summary:
Also makes -fcoroutines_ts to be both a Driver and CC1 flag.
Patch mostly by EricWF.
Reviewers: rnk, cfe-commits, rsmith, EricWF
Subscribers: mehdi_amini
Differential Revision: https://reviews.llvm.org/D25130
llvm-svn: 283064
assume that ::operator new provides no more alignment than is necessary for any
primitive type, except when we're on a GNU OS, where glibc's malloc guarantees
to provide 64-bit alignment on 32-bit systems and 128-bit alignment on 64-bit
systems. This can be controlled by the command-line -fnew-alignment flag.
llvm-svn: 282974
This patch corresponds to review:
https://reviews.llvm.org/D24397
It adds the __POWER9_VECTOR__ macro and the -mpower9-vector option along with
a number of altivec.h functions (refer to the code review for a list).
llvm-svn: 282481
Like NetBSD, OpenBSD prefers having a consistent set of typedefs
across the architectures it supports over strictly following the ARM
ABIs. The diff below makes sure that clang's view of those types
matches OpenBSD's system header files. It also adds a test that
checks the relevant types on all OpenBSD platforms that clang works
on. Hopefully we can add mips64 and powerpc to that list in the
future.
Patch by Mark Kettenis <mark.kettenis@xs4all.nl>
llvm-svn: 282184
Fix target options for fp32/64-denormals so that
+fp64-denormals is set if fp64 is supported
-fp32-denormals if fp32 denormals is not supported, or -cl-denorms-are-zero is set
+fp32-denormals if fp32 denormals is supported and -cl-denorms-are-zero is not set
If target feature fp32/64-denormals is explicitly set, they will override default options and options deduced from -cl-denorms-are-zero.
Differential Revision: https://reviews.llvm.org/D24512
llvm-svn: 281357
Summary:
This fixes a bug where we were unable to compile the following CUDA
file with libstdc++ (didn't try libc++):
#include <future>
void foo() { std::shared_future<int> x; }
The problem is that <future> only defines std::shared_future if
__GCC_ATOMIC_INT_LOCK_FREE > 1. When we compiled this file for device,
the macro was set to 1, and then the class didn't exist at all.
Reviewers: tra
Subscribers: cfe-commits, jhen
Differential Revision: https://reviews.llvm.org/D24407
llvm-svn: 281089
OpenCL requires __ENDIAN_LITTLE__ be set for little endian targets.
The default for targets was also apparently big endian, so AMDGPU
was incorrectly reported as big endian. Set this from the triple
so targets don't have another place to set the endianness.
llvm-svn: 280787
I'm in the progress of adding ARMv6 support to CloudABI. On the compiler
side, everything seems to work properly with this tiny change applied.
llvm-svn: 280672
This adds support for modules that require (non-)freestanding
environment, such as the compiler builtin mm_malloc submodule.
Differential Revision: https://reviews.llvm.org/D23871
llvm-svn: 280613
Summary:
We want wasm and asmjs to have matching ABIs, and right now asmjs uses
unsigned int for its size_t. This causes exported symbols in libcxx to
not match and can cause weird breakage where libcxx doesn't get linked
as a result. Long-term we probably want wasm32, wasm64, and asmjs to
all use unsigned long, but that would cause unnecessary ABI churn for
asmjs so defer that until we can make all the ABI changes at once.
Patch by Jacob Gravelle
Differential Revision: https://reviews.llvm.org/D24134
llvm-svn: 280420
This adds support for modules that require (no-)gnu-inline-asm
environment, such as the compiler builtin cpuid submodule.
This is the gnu-inline-asm variant of https://reviews.llvm.org/D23871
Differential Revision: https://reviews.llvm.org/D23905
rdar://problem/26931199
llvm-svn: 280159
Pointers of certain GPUs in AMDGCN target in private address space is 32 bit but pointers in other address spaces are 64 bit. size_t type should be defined as 64 bit for these GPUs so that it could hold pointers in all address spaces. Also fixed issues in pointer arithmetic codegen by using pointer specific intptr type.
Differential Revision: https://reviews.llvm.org/D23361
llvm-svn: 279121
This reverts commit r279003 as it breaks some of our buildbots (e.g.
clang-cmake-aarch64-quick, clang-x86_64-linux-selfhost-modules).
The error is in OpenMP/teams_distribute_simd_ast_print.cpp:
clang: /home/buildslave/buildslave/clang-cmake-aarch64-quick/llvm/include/llvm/ADT/DenseMap.h:527:
bool llvm::DenseMapBase<DerivedT, KeyT, ValueT, KeyInfoT, BucketT>::LookupBucketFor(const LookupKeyT&, const BucketT*&) const
[with LookupKeyT = clang::Stmt*; DerivedT = llvm::DenseMap<clang::Stmt*, long unsigned int>;
KeyT = clang::Stmt*; ValueT = long unsigned int;
KeyInfoT = llvm::DenseMapInfo<clang::Stmt*>;
BucketT = llvm::detail::DenseMapPair<clang::Stmt*, long unsigned int>]:
Assertion `!KeyInfoT::isEqual(Val, EmptyKey) && !KeyInfoT::isEqual(Val, TombstoneKey) &&
"Empty/Tombstone value shouldn't be inserted into map!"' failed.
llvm-svn: 279045
This patch is to implement sema and parsing for 'teams distribute simd’ pragma.
This patch is originated by Carlo Bertolli.
Differential Revision: https://reviews.llvm.org/D23528
llvm-svn: 279003
Reapply r278457 with test fixed to not abouse fs case sensitivity.
When the VFS uses a YAML file, the real file path for a
virtual file is described in the "external-contents" field. Example:
...
{
'type': 'file',
'name': 'a.h',
'external-contents': '/a/b/c/a.h'
}
Currently, when parsing umbrella directories, we use
vfs::recursive_directory_iterator to gather the header files to generate the
equivalent modules for. If the external contents for a header does not exist,
we currently are unable to build a module, since the VFS
vfs::recursive_directory_iterator will fail when it finds an entry without a
reliable real path.
Since the YAML file could be prepared ahead of time and shared among
different compiler invocations, an entry might not yet have a reliable
path in 'external-contents', breaking the iteration.
Give the VFS the capability to skip such entries whenever
'ignore-non-existent-contents' property is set in the YAML file.
rdar://problem/27531549
llvm-svn: 278543
When the VFS uses a YAML file, the real file path for a
virtual file is described in the "external-contents" field. Example:
...
{
'type': 'file',
'name': 'a.h',
'external-contents': '/a/b/c/a.h'
}
Currently, when parsing umbrella directories, we use
vfs::recursive_directory_iterator to gather the header files to generate the
equivalent modules for. If the external contents for a header does not exist,
we currently are unable to build a module, since the VFS
vfs::recursive_directory_iterator will fail when it finds an entry without a
reliable real path.
Since the YAML file could be prepared ahead of time and shared among
different compiler invocations, an entry might not yet have a reliable
path in 'external-contents', breaking the iteration.
Give the VFS the capability to skip such entries whenever
'ignore-non-existent-contents' property is set in the YAML file.
rdar://problem/27531549
llvm-svn: 278457
Add 'ignore-non-existent-contents' to tell the VFS whether an invalid path
obtained via 'external-contents' should cause iteration on the VFS to stop.
If 'true', the VFS should ignore the entry and continue with the next. Allows
YAML files to be shared across multiple compiler invocations regardless of
prior existent paths in 'external-contents'. This global value is overridable
on a per-file basis.
This adds the parsing and write test part, but use by VFS comes next.
Differential Revision: https://reviews.llvm.org/D23422
rdar://problem/27531549
llvm-svn: 278456
Adjust target features for amdgcn target when -cl-denorms-are-zero is set.
Denormal support is controlled by feature strings fp32-denormals fp64-denormals in amdgcn target. If -cl-denorms-are-zero is not set and the command line does not set fp32/64-denormals feature string, +fp32-denormals +fp64-denormals will be on for GPU's supporting them.
A new virtual function virtual void TargetInfo::adjustTargetOptions(const CodeGenOptions &CGOpts, TargetOptions &TargetOpts) const is introduced to allow adjusting target option by codegen option.
Differential Revision: https://reviews.llvm.org/D22815
llvm-svn: 278151
The size of image type is reported incorrectly as size of a pointer to address space 0, which causes error when casting image type to pointers by __builtin_astype.
The fix is to get image address space from TargetInfo then report the size accordingly.
Differential Revision: https://reviews.llvm.org/D22927
llvm-svn: 277647
Adding extension cl_khr_mipmap_image to clang's OpenCL Extensions and initiated inside AMDGPU Target.
Patch by Aaron En Ye Shi.
Differential Revision: https://reviews.llvm.org/D22637
llvm-svn: 277181
This resubmit r270688 which broke some specific buildbots.That's because
there is incorrect indexing problem in the targetparser,and the problem is
fixed in r276957.
Differential Revision: https://reviews.llvm.org/D21277
llvm-svn: 276958
Summary:
In RenderScript, the size of the argument or return value emitted in the
IR is expected to be the same as the size of corresponding qualified
type. For ARM and AArch64, the coercion performed by Clang can
change the parameter or return value to a type whose size is different
(usually larger) than the original aggregate type. Specifically, this
can happen in the following cases:
- Aggregate parameters of size <= 64 bytes and return values smaller
than 4 bytes on ARM
- Aggregate parameters and return values smaller than bytes on
AArch64
This patch coerces the cases above to an integer array that is the same
size and alignment as the original aggregate. A new field is added to
TargetInfo to detect a RenderScript target and limit this coercion just
to that case.
Tests added to test/CodeGen/renderscript.c
Reviewers: rsmith
Subscribers: aemerson, srhines, llvm-commits
Differential Revision: https://reviews.llvm.org/D22822
llvm-svn: 276904
Summary:
N32 and N64 follow the standard ELF conventions (.L) whereas O32 uses its own
($).
This fixes the majority of object differences between -fintegrated-as and
-fno-integrated-as.
Reviewers: sdardis
Subscribers: dsanders, sdardis, llvm-commits
Differential Revision: https://reviews.llvm.org/D22412
llvm-svn: 275967
This patch is to implement sema and parsing for 'target parallel for simd' pragma.
Differential Revision: http://reviews.llvm.org/D22096
llvm-svn: 275365
http://reviews.llvm.org/D21904
This patch is similar to the implementation of 'private' clause: it adds a list of private pointers to be used within the target data region to store the device pointers returned by the runtime.
Please refer to the following document for a full description of what the runtime witll return in this case (page 10 and 11):
https://github.com/clang-omp/OffloadingDesign
I am happy to answer any question related to the runtime interface to help reviewing this patch.
llvm-svn: 275271
Some compilers are too dumb to realize that the switch statement covers
all cases.
(Don't use a "default" label, because we explicitly want to get a warning
if our switch doesn't cover all the cases.)
llvm-svn: 274713
Summary:
Currently our handling of CUDA architectures is scattered all around
clang. This patch centralizes it.
A key advantage of this centralization is that you can now write a C++
switch on e.g. CudaArch and get a compile error if you don't handle one
of the enum values.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D21867
llvm-svn: 274681
Summary: Also add sm_32, which was missing.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D21778
llvm-svn: 274680
Summary: This patch is an implementation of sema and parsing for the OpenMP composite pragma 'distribute simd'.
Differential Revision: http://reviews.llvm.org/D22007
llvm-svn: 274604
Summary: This patch is an implementation of sema and parsing for the OpenMP composite pragma 'distribute parallel for simd'.
Differential Revision: http://reviews.llvm.org/D21977
llvm-svn: 274530
Currently we only have OpenCL 2.0 Builtins i.e. pipes or address space conversions.
They have to be added only in the version 2.0 compilation mode to make the identifiers
available for use in the other versions.
Review: http://reviews.llvm.org/D20249
llvm-svn: 274509
Summary: This change exposes the recently added LEON CPUs (D19359) in the LLVM Sparc backend to Clang, allowing the cpu's to be selected using the -mcpu flag.
Reviewers: jyknight, lero_chris
Subscribers: jyknight, cfe-commits
Differential Revision: http://reviews.llvm.org/D21683
llvm-svn: 274487
Summary:
The TargetInfo for 'renderscript32' and 'renderscript64' ArchTypes are
subclasses of ARMleTargetInfo and AArch64leTargetInfo respectively.
RenderScript32TargetInfo modifies the ARM ABI to set LongWidth and
LongAlign to be 64-bits. Other than this modification, the underlying
TargetInfo base classes is initialized as if they have "armv7" and
"aarch64" architecture type respectively.
Reviewers: rsmith, echristo
Subscribers: aemerson, tberghammer, cfe-commits, danalbert, mehdi_amini, srhines
Differential Revision: http://reviews.llvm.org/D21334
llvm-svn: 274409
Summary:
Summary:
Change Clang calling convention SpirKernel to OpenCLKernel.
Set calling convention OpenCLKernel for amdgcn as well.
Add virtual method .getOpenCLKernelCallingConv() to TargetCodeGenInfo
and use it to set target calling convention for AMDGPU and SPIR.
Update tests.
Reviewers: rsmith, tstellarAMD, Anastasia, yaxunl
Subscribers: kzhuravl, cfe-commits
Differential Revision: http://reviews.llvm.org/D21367
llvm-svn: 274220
We continue accepting "macosx" but canonicalize it to "macos", When emitting
diagnostics, we use "macOS" instead of "OS X".
The PlatformName in TargetInfo is changed from "macosx" to "macos" so we can
directly compare the Platform in AvailabilityAttr with the PlatformName
in TargetInfo.
rdar://26795172
rdar://26800775
llvm-svn: 274064
The final change is required to extend the back-end's AtomicExpandPass that was implemented for Sparc (64 bit) and later extended for Sparc (32 bit).
llvm-svn: 274012
Recently, Microsoft added support for a flag, /std, which controls which
version of the language rules MSVC should use.
MSVC hasn't updated __cplusplus though.
Instead, they added a new macro, _MSVC_LANG, which is defined in a
similar fashion to __cplusplus. This is used to indicate which mode the
compiler is in.
llvm-svn: 273987
[OpenMP] Initial implementation of parse and sema for composite pragma 'distribute parallel for'
This patch is an initial implementation for #distribute parallel for.
The main differences that affect other pragmas are:
The implementation of 'distribute parallel for' requires blocking of the associated loop, where blocks are "distributed" to different teams and iterations within each block are scheduled to parallel threads within each team. To implement blocking, sema creates two additional worksharing directive fields that are used to pass the team assigned block lower and upper bounds through the outlined function resulting from 'parallel'. In this way, scheduling for 'for' to threads can use those bounds.
As a consequence of blocking, the stride of 'distribute' is not 1 but it is equal to the blocking size. This is returned by the runtime and sema prepares a DistIncrExpr variable to hold that value.
As a consequence of blocking, the global upper bound (EnsureUpperBound) expression of the 'for' is not the original loop upper bound (e.g. in for(i = 0 ; i < N; i++) this is 'N') but it is the team-assigned block upper bound. Sema creates a new expression holding the calculation of the actual upper bound for 'for' as UB = min(UB, PrevUB), where UB is the loop upper bound, and PrevUB is the team-assigned block upper bound.
llvm-svn: 273884
I added this option in r257827 to try and add compatibility with autoconf. At the time I misunderstood the problem.
Our CMake automatically generates the SVN revision information and generates a build action to update it so builds don't need to be re-configured on SCM update (which is a better solution than we had in autoconf).
The problem I was actually seeing was isolated cases where SVN revision information isn't available because the repository structures have been removed. This happens in some automated testing systems.
This patch allows SVN_REVISION to be overridden if the build configuration could not find the SCM repository structures, and removes the code from my original patch because it is unnecessary.
llvm-svn: 273714
http://reviews.llvm.org/D21564
This patch is an initial implementation for #distribute parallel for.
The main differences that affect other pragmas are:
The implementation of 'distribute parallel for' requires blocking of the associated loop, where blocks are "distributed" to different teams and iterations within each block are scheduled to parallel threads within each team. To implement blocking, sema creates two additional worksharing directive fields that are used to pass the team assigned block lower and upper bounds through the outlined function resulting from 'parallel'. In this way, scheduling for 'for' to threads can use those bounds.
As a consequence of blocking, the stride of 'distribute' is not 1 but it is equal to the blocking size. This is returned by the runtime and sema prepares a DistIncrExpr variable to hold that value.
As a consequence of blocking, the global upper bound (EnsureUpperBound) expression of the 'for' is not the original loop upper bound (e.g. in for(i = 0 ; i < N; i++) this is 'N') but it is the team-assigned block upper bound. Sema creates a new expression holding the calculation of the actual upper bound for 'for' as UB = min(UB, PrevUB), where UB is the loop upper bound, and PrevUB is the team-assigned block upper bound.
llvm-svn: 273705
Summary:
The validity of ABI/CPU pairs is no longer checked on the fly but is
instead checked after initialization. As a result, invalid CPU/ABI pairs
can be reported as being known but invalid instead of being unknown. For
example, we now emit:
error: ABI 'n32' is not supported on CPU 'mips32r2'
instead of:
error: unknown target ABI 'n64'
Reviewers: atanasyan
Subscribers: sdardis, cfe-commits
Differential Revision: http://reviews.llvm.org/D21023
llvm-svn: 272645
Differential Revision: http://reviews.llvm.org/D19843
Corresponding LLVM change: http://reviews.llvm.org/D19842
Re-commit after addressing issues with of generating too many warnings for Windows and asan test failures.
Patch by Eric Niebler
llvm-svn: 272562
Summary:
setABI() is still tied to the Arch component of the Triple to preserve existing
behaviour.
Reviewers: atanasyan
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D20961
llvm-svn: 271875
Summary:
There are no llvm backend tests* for EABI and no EABI buildbots. There were only
three clang tests, all of which checked that -mabi=eabi was passed to the
assembler.
*There is a single backend test that specifies EABI but it actually tests MIPS16.
Reviewers: atanasyan
Subscribers: emaste, sdardis, atanasyan, cfe-commits
Differential Revision: http://reviews.llvm.org/D20679
llvm-svn: 270998
Summary:
This unifies mips/mipsel and mips64/mips64el into a single class so that we can
later support O32 on mips64/mips64el and N32/N64 on mips/mipsel (when an
appropriate CPU selected).
Reviewers: atanasyan
Subscribers: atanasyan, jfb, cfe-commits, dschuff
Differential Revision: http://reviews.llvm.org/D20678
llvm-svn: 270984
Summary:
The patch contains the parsing and sema support for the `from` clause.
Patch based on the original post by Kelvin Li.
Reviewers: hfinkel, carlo.bertolli, kkwli0, arpith-jacob, ABataev
Subscribers: caomhin, cfe-commits
Differential Revision: http://reviews.llvm.org/D18488
llvm-svn: 270882
Summary:
The patch contains the parsing and sema support for the `to` clause.
Patch based on the original post by Kelvin Li.
Reviewers: carlo.bertolli, hfinkel, kkwli0, arpith-jacob, ABataev
Subscribers: caomhin, cfe-commits
Differential Revision: http://reviews.llvm.org/D18597
llvm-svn: 270880
Summary:
This patch is to add parsing and sema support for `target update` directive. Support for the `to` and `from` clauses will be added by a different patch. This patch also adds support for other clauses that are already implemented upstream and apply to `target update`, e.g. `device` and `if`.
This patch is based on the original post by Kelvin Li.
Reviewers: hfinkel, carlo.bertolli, kkwli0, arpith-jacob, ABataev
Subscribers: caomhin, cfe-commits
Differential Revision: http://reviews.llvm.org/D15944
llvm-svn: 270878
This reverts commit r270688 and r270689. The issue is not a random order, but a
different order for some targets and others (prob. Linux vs Darwin). Reverting until
we have a better fix.
llvm-svn: 270691
Using AArch64TargetParser in clang to avoid repetitive string parsing.
Use TargetParser to do ARCH/CPU/ArchExt parsing instead of local implementation.
Patch by Jojo Ma.
llvm-svn: 270688
Summary:
Following patch D19265 which enable software floating point support in the Sparc backend, this patch enables the option to be enabled in the front-end using the -msoft-float option.
The user should ensure a library (such as the builtins from Compiler-RT) that includes the software floating point routines is provided.
Reviewers: jyknight, lero_chris
Subscribers: jyknight, cfe-commits
Differential Revision: http://reviews.llvm.org/D20419
llvm-svn: 270538
The `FreeBSDTargetInfo` class has always set the `__FreeBSD_cc_version`
predefined macro to a rather static value, calculated from the major OS
version.
In the FreeBSD base system, we will start incrementing the value of this
macro whenever we make any signifant change to clang, so we need a way
to configure the macro's value at build time.
Use `FREEBSD_CC_VERSION` for this, which we can define in the FreeBSD
build system using either the `-D` command line option, or an include
file. Stock builds will keep the earlier value.
Differential Revision: http://reviews.llvm.org/D20037
llvm-svn: 270240
This is matching what trunk gcc is accepting. Also adds a missing ssse3
case. PR27779. The amount of duplication here is annoying, maybe it
should be factored into a separate .def file?
llvm-svn: 270224
Summary:
MONITORX/MWAITX instructions provide similar capability to the MONITOR/MWAIT
pair while adding a timer function, such that another termination of the MWAITX
instruction occurs when the timer expires. The presence of the MONITORX and
MWAITX instructions is indicated by CPUID 8000_0001, ECX, bit 29.
The MONITORX and MWAITX instructions are intercepted by the same bits that
intercept MONITOR and MWAIT. MONITORX instruction establishes a range to be
monitored. MWAITX instruction causes the processor to stop instruction
execution and enter an implementation-dependent optimized state until
occurrence of a class of events.
Opcode of MONITORX instruction is "0F 01 FA". Opcode of MWAITX instruction is
"0F 01 FB". These opcode information is used in adding tests for the
disassembler.
These instructions are enabled for AMD's bdver4 architecture.
Patch by Ganesh Gopalasubramanian!
Reviewers: echristo, craig.topper
Subscribers: RKSimon, joker.eph, llvm-commits, cfe-commits
Differential Revision: http://reviews.llvm.org/D19796
llvm-svn: 269907
licensees actually see in the toolchain we deliver to them. This will
reduce the set of local patches we have to maintain. The triple is
not changing. (The term ORBIS is an internal code name for PS4.)
llvm-svn: 269671
Add supported OpenCL extensions to target info. It serves as default values to save the users of the burden setting each supported extensions and optional core features in command line.
Re-commit after fixing build error due to missing override attribute.
Differential Revision: http://reviews.llvm.org/D19484
llvm-svn: 269670
Embedded ARM MachO targets are AAPCS but not full EABI (we don't use
__aeabi_whatever and the functions are allowed to be hard-float).
Turns out there was already a test for this, but its original purpose had
become corrupted over the years.
llvm-svn: 269487
Revert r269431 due to build failure caused by warning msg:
llvm/tools/clang/lib/Basic/Targets.cpp:2090:9: error: 'setSupportedOpenCLOpts' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
void setSupportedOpenCLOpts() {
llvm-svn: 269435
Add supported OpenCL extensions to target info. It serves as default values to save the users of the burden setting each supported extensions and optional core features in command line.
Differential Revision: http://reviews.llvm.org/D19484
llvm-svn: 269431
Reapply r269100 and r269270, reverted due to
https://llvm.org/bugs/show_bug.cgi?id=27725. Isolate the testcase that
corresponds to the new feature side of this commit and skip it on
windows hosts until we find why it does not work on these platforms.
Original commit message:
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
Build a proper virtual directory tree out of the YAML representation,
allowing faster search and proper iteration. Besides the crash
reproducer, this potentially benefits other VFS clients.
llvm-svn: 269327
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
This patch builds a proper virtual directory tree out of the YAML
representation, allowing faster search and proper iteration. Besides the
crash reproducer, this potentially benefits other VFS clients.
llvm-svn: 269270
[ Copied from https://llvm.org/bugs/show_bug.cgi?id=26404 ]
clang support on Haiku is lagging a bit, and missing on x86_64.
This patch updates support for x86 and add support for x86_64. It should
apply directly to trunk and it's harmless in the sense that it only
affects Haiku.
Reviewers: rnk, rsmith
Patch by Jérôme Duval
Differential Revision: http://reviews.llvm.org/D16797
llvm-svn: 269201
Bruno made a couple valiant attempts but the bot is still red.
This reverts r269100 (primary commit), r269108 (fix attempt), r269133
(fix attempt).
llvm-svn: 269160
The way we currently build the internal VFS overlay representation leads
to inefficient path search and might yield wrong answers when asked for
recursive or regular directory iteration.
Currently, when reading an YAML file, each YAML root entry is placed
inside a new root in the filesystem overlay. In the crash reproducer, a
simple "@import Foundation" currently maps to 43 roots, and when looking
up paths, we traverse a directory tree for each of these different
roots, until we find a match (or don't). This has two consequences:
- It's slow.
- Directory iteration gives incomplete results since it only return
results within one root - since contents of the same directory can be
declared inside different roots, the result isn't accurate.
This is in part fault of the way we currently write out the YAML file
when emitting the crash reproducer - we could generate only one root and
that would make it fast and correct again. However, we should not rely
on how the client writes the YAML, but provide a good internal
representation regardless.
This patch builds a proper virtual directory tree out of the YAML
representation, allowing faster search and proper iteration. Besides the
crash reproducer, this potentially benefits other VFS clients.
llvm-svn: 269100
This patch corresponds to review:
http://reviews.llvm.org/D19684
It simply adds the handling for the option and the corresponding macros.
llvm-svn: 268951
This patch corresponds to reviews:
http://reviews.llvm.org/D15120http://reviews.llvm.org/D19125
It adds support for the __float128 keyword, literals and target feature to
enable it. Based on the latter of the two aforementioned reviews, this feature
is enabled on Linux on i386/X86 as well as SystemZ.
This is also the second attempt in commiting this feature. The first attempt
did not enable it on required platforms which caused failures when compiling
type_traits with -std=gnu++11.
If you see failures with compiling this header on your platform after this
commit, it is likely that your platform needs to have this feature enabled.
llvm-svn: 268898
This code implements builtin_setjmp and builtin_longjmp exception handling intrinsics for 32-bit Sparc back-ends.
The code started as a mash-up of the PowerPC and X86 versions, although there are sufficient differences to both that had to be made for Sparc handling.
Note: I have manual tests running. I'll work on a unit test and add that to the rest of this diff in the next day.
Also, this implementation is only for 32-bit Sparc. I haven't focussed on a 64-bit version, although I have left the code in a prepared state for implementing this, including detecting pointer size and comments indicating where I suspect there may be differences.
Differential Revision: http://reviews.llvm.org/D19798
llvm-svn: 268483
The -malign-double flag causes i64 and f64 types to have alignment 8
instead of 4. On x86-64, the behavior of -malign-double is enabled by default.
Rebases and cleans phosek's work here: http://reviews.llvm.org/D12860
Patch by Sean Klein
Reviewers: rnk
Subscribers: rnk, jfb, dschuff, phosek
Differential Revision: http://reviews.llvm.org/D19734
llvm-svn: 268473
Summary:
Host and device types must match, otherwise when we pass values back and
forth between the host and device, we will get the wrong result.
This patch makes NVPTXTargetInfo inherit most of its type information
from the host's target info.
Reviewers: rsmith
Subscribers: cfe-commits, jhen, tra
Differential Revision: http://reviews.llvm.org/D19346
llvm-svn: 268131
Summary: The Darwin armv7k ABI uses Dwarf EH, so we need to set the OS define correctly. Without this the gcc_personality fails to build.
Reviewers: t.p.northover
Subscribers: aemerson, cfe-commits, rengolin
Differential Revision: http://reviews.llvm.org/D19693
llvm-svn: 268078
It's a little debateable because we're not truly AAPCS, so I'm
certainly not going to define __ARM_PCS, but __ARM_PCS_VFP seems to be
really an "hard-float" define, which is a useful thing to have.
llvm-svn: 267880
Summary:
Port rL265324 to SystemZ to allow using the 'swiftcall' attribute on that architecture.
Depends on D19414.
Reviewers: kbarton, rjmccall, uweigand
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19432
llvm-svn: 267879
Summary:
According to the ACLE spec, "__ARM_FEATURE_FMA is defined to 1 if
the hardware floating-point architecture supports fused floating-point
multiply-accumulate".
This changes clang's behaviour from emitting this macro for v7-A and v7-R
cores to only emitting it when the target has VFPv4 (and therefore support
for the floating point multiply-accumulate instruction).
Fixes PR27216
Reviewers: t.p.northover, rengolin
Subscribers: aemerson, rengolin, cfe-commits
Differential Revision: http://reviews.llvm.org/D18963
llvm-svn: 267869
Since this patch provided support for the __float128 type but disabled it
on all platforms by default, some platforms can't compile type_traits with
-std=gnu++11 since there is a specialization with __float128.
This reverts the patch until D19125 is approved (i.e. we know which platforms
need this support enabled).
llvm-svn: 266460
Hide the real paths when rebuilding from VFS by setting up the crash
reproducer to use 'use-external-names' = false. This way we avoid
module redifinition errors and consistently use the same paths against
all modules.
With this change on Darwin we are able to simulate a crash for a simple
application using "Foundation/Foundation.h" (which relies on a bunch of
different frameworks and headers) and successfully rebuild all the
modules by relying solely at the VFS overlay.
llvm-svn: 266234
This patch corresponds to review:
http://reviews.llvm.org/D15120
It adds support for the __float128 keyword, literals and a target feature to
enable it. This support is disabled by default on all targets and any target
that has support for this type is free to add it.
Based on feedback that I've received from target maintainers, this appears to
be the right thing for most targets. I have not heard from the maintainers of
X86 which I believe supports this type. I will subsequently investigate the
impact of enabling this on X86.
llvm-svn: 266186
addAncestorsAsVirtualDirs("<stdin>") quickly returns without doing work
because "<stdin>" has no parent_path. This violates the expectation
that a subsequent call to getDirectoryFromFile("<stdin>") would succeed.
Instead, it fails because it uses the "." if the file has no path
component.
Fix this by keeping the behavior between addAncestorsAsVirtualDirs and
getDirectoryFromFile symmetric.
llvm-svn: 266089
OpenMP 4.0 defines clause 'uniform' in 'declare simd' directive:
'uniform' '(' <argument-list> ')'
The uniform clause declares one or more arguments to have an invariant value for all concurrent invocations of the function in the execution of a single SIMD loop.
The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses.
llvm-svn: 266041
The GNU profiling support indicates that the interface is `_mcount` rather than
`mcount`. Conditionalise the behaviour according to the `-meabi gnu` flag.
Resolves PR27311
llvm-svn: 266039
It seems that there was a miscommunication between Renato and I, and the
original behaviour of AArch64 was to be preserved and not to mirror the new
behaviour. Restore the original behaviour for AArch64. Addresses post-commit
review comments from Renato Golin.
llvm-svn: 265899
This adds support to optionally support using `__gnu_mcount_nc` as the mcount
interface rather than `mcount` for Linux and EABI. The other targets do not
provide an implementation for `__gnu_mcount_nc`. This can be activated via the
`-meabi gnu` flag.
Resolves PR23969.
llvm-svn: 265888
This threads TargetOptions into the TargetInfo hierarchy. This is a rework of
the original attempt to thread additional information into the TargetInfo to
make decisions based on additional ABI related options.
llvm-svn: 265878
Revert the two changes to thread CodeGenOptions into the TargetInfo allocation
and to fix the layering violation by moving CodeGenOptions into Basic.
Code Generation is arguably not particularly "basic". This addresses Richard's
post-commit review comments. This change purely does the mechanical revert and
will be followed up with an alternate approach to thread the desired information
into TargetInfo.
llvm-svn: 265806
This is a mechanical move of CodeGenOptions from libFrontend to libBasic. This
fixes the layering violation introduced earlier by threading CodeGenOptions into
TargetInfo. It should also fix the modules based self-hosting builds. NFC.
llvm-svn: 265702
This threads CodeGenOptions into the TargetInfo hierarchy. This is motivated by
ARM which can change some target information based on the EABI selected
(-meabi). Similar options exist for other platforms (e.g. MIPS) and thus is
generally useful. NFC.
llvm-svn: 265640
Add parsing, sema analysis for 'declare target' construct for OpenMP 4.0
(4.5 support will be added in separate patch).
The declare target directive specifies that variables, functions (C, C++
and Fortran), and subroutines (Fortran) are mapped to a device. The declare
target directive is a declarative directive. In Clang declare target is
implemented as implicit attribute for the declaration.
The syntax of the declare target directive is as follows:
#pragma omp declare target
declarations-definition-seq
#pragma omp end declare target
Based on patch from Michael Wong http://reviews.llvm.org/D15321
llvm-svn: 265530
alignment on Darwin.
Itanium C++ ABI specifies that _Unwind_Exception should be double-word
aligned (16B). To conform to the ABI, libraries implementing exception
handling declare the struct with __attribute__((aligned)), which aligns
the unwindHeader field (and the end of __cxa_exception) to the default
target alignment (which is typically 16-bytes).
struct __cxa_exception {
...
// struct is declared with __attribute__((aligned)).
_Unwind_Exception unwindHeader;
};
Based on the assumption that _Unwind_Exception is declared with
__attribute__((aligned)), ItaniumCXXABI::getAlignmentOfExnObject returns
the target default alignment for __attribute__((aligned)). It turns out
that libc++abi, which is used on Darwin, doesn't declare the struct with
the attribute and therefore doesn't guarantee that unwindHeader is
aligned to the alignment specified by the ABI, which in some cases
causes the program to crash because of unaligned memory accesses.
This commit avoids crashes due to unaligned memory accesses by having
getAlignmentOfExnObject return an 8-byte alignment on Darwin. I've only
fixed the problem for Darwin, but we should also figure out whether other
platforms using libc++abi need similar fixes.
rdar://problem/25314277
Differential revision: http://reviews.llvm.org/D18479
llvm-svn: 264998
The VFS YAML files contain empty directory entries to describe that it's
returning from a subdirectory before describing new files in the parent.
In the future, we should properly sort and write YAML files avoiding
such empty dirs and mitigate the extra recurson cost. However, since
this is used by previous existing YAMLs, make the traversal work in
their presence.
rdar://problem/24499339
llvm-svn: 264970
BuiltinsSystemZ.def is extended to include the required processor
features per intrinsic.
New test test/CodeGen/builtins-systemz-error2.c that checks for
expected errors when instrinsics are used with a subtarget that does
not support the required feature (e.g. vector support).
Reviewed by Ulrich Weigand.
llvm-svn: 264873
Initial parsing/sema/serialization/deserialization support for '#pragma
omp declare simd' directive.
The 'declare simd' construct can be applied to a function to enable the
creation of one or more versions that can process multiple arguments
using SIMD instructions from a single invocation from a SIMD loop.
If the function has any declarations, then the declare simd construct
for any declaration that has one must be equivalent to the one specified
for the definition. Otherwise, the result is unspecified.
This pragma can be applied many times to the same declaration.
Internally this pragma is represented as an attribute. But we need special processing for this pragma because it must be used before function declaration, this directive is applied to.
Differential Revision: http://reviews.llvm.org/D10599
llvm-svn: 264853
The FileSystem::makeAbsolute function has been calculating the current
working directory unconditionally, even when it is not needed. This calls
down to llvm::sys::fs::current_path, which is relatively expensive
because it stats two directories, regardless of whether those paths are
already in the stat cache. The net effect is that when using the
VFS, every stat during header search turns into three stats. With this
change, we get back to a single stat for absolute directory paths.
llvm-svn: 264519
Summary:
The two literals are currently appended.
I'm not sure what was broken by this. Please double check carefully.
Silly bug found by an on-going checker for clang-tidy.
Reviewers: alexfh, arsenm, rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18454
llvm-svn: 264315
This reapplies r261552 and r263748. Fixed testcase to reapply.
The VFS overlay mapping between virtual paths and real paths is done through
the 'external-contents' entries in YAML files, which contains hardcoded paths
to the real files.
When a module compilation crashes, headers are dumped into <name>.cache/vfs
directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script
generated for reproduction uses -ivfsoverlay pointing to file to gather the
mapping between virtual paths and files inside <name>.cache/vfs. Currently, we
are only capable of reproducing such crashes in the same machine as they
happen, because of the hardcoded paths in 'external-contents'.
To be able to reproduce a crash in another machine, this patch introduces a new
option in the VFS yaml file called 'overlay-relative'. When it's equal to
'true' it means that the provided path to the YAML file through the
-ivfsoverlay option should also be used to prefix the final path for every
'external-contents'.
Example, given the invocation snippet "... -ivfsoverlay
<name>.cache/vfs/vfs.yaml" and the following entry in the yaml file:
"overlay-relative": "true",
"roots": [
...
"type": "directory",
"name": "/usr/include",
"contents": [
{
"type": "file",
"name": "stdio.h",
"external-contents": "/usr/include/stdio.h"
},
...
Here, a file manager request for virtual "/usr/include/stdio.h", that will map
into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h.
This is a useful feature for debugging module crashes in machines other than
the one where the error happened.
Differential Revision: http://reviews.llvm.org/D17457
rdar://problem/24499339
llvm-svn: 263893
This reapplies r261552.
The VFS overlay mapping between virtual paths and real paths is done through
the 'external-contents' entries in YAML files, which contains hardcoded paths
to the real files.
When a module compilation crashes, headers are dumped into <name>.cache/vfs
directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script
generated for reproduction uses -ivfsoverlay pointing to file to gather the
mapping between virtual paths and files inside <name>.cache/vfs. Currently, we
are only capable of reproducing such crashes in the same machine as they
happen, because of the hardcoded paths in 'external-contents'.
To be able to reproduce a crash in another machine, this patch introduces a new
option in the VFS yaml file called 'overlay-relative'. When it's equal to
'true' it means that the provided path to the YAML file through the
-ivfsoverlay option should also be used to prefix the final path for every
'external-contents'.
Example, given the invocation snippet "... -ivfsoverlay
<name>.cache/vfs/vfs.yaml" and the following entry in the yaml file:
"overlay-relative": "true",
"roots": [
...
"type": "directory",
"name": "/usr/include",
"contents": [
{
"type": "file",
"name": "stdio.h",
"external-contents": "/usr/include/stdio.h"
},
...
Here, a file manager request for virtual "/usr/include/stdio.h", that will map
into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h.
This is a useful feature for debugging module crashes in machines other than
the one where the error happened.
Differential Revision: http://reviews.llvm.org/D17457
rdar://problem/24499339
llvm-svn: 263748
This was applied twice r261551 and 263617 and later reverted because:
(1) Windows bot failing on unittests. Change the current behavior to do
not handle path traversals on windows.
(2) Windows bot failed to include llvm/Config/config.h in order to use
HAVE_REALPATH. Use LLVM_ON_UNIX instead, as done in lib/Basic/FileManager.cpp.
Handle ".", ".." and "./" with trailing slashes while collecting files
to be dumped into the vfs overlay directory.
Include the support for symlinks into components. Given the path:
/install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin"
component is a symlink, it's not safe to use `path::remove_dots` here,
and `realpath` is used to get the right answer. Since `realpath`
is expensive, we only do it at collecting time (which only happens
during the crash reproducer) and cache the base directory for fast lookups.
Overall, this makes the input to the VFS YAML file to be canonicalized
to never contain traversal components.
Differential Revision: http://reviews.llvm.org/D17104
rdar://problem/24499339
llvm-svn: 263686
Till now, preserve_mostcc/preserve_allcc calling convention attributes were only
available at the LLVM IR level. This patch adds attributes for
preserve_mostcc/preserve_allcc calling conventions to the C/C++ front-end.
The code was mostly written by Juergen Ributzka.
I just added support for the AArch64 target and tests.
Differential Revision: http://reviews.llvm.org/D18025
llvm-svn: 263647
This is originally r261551, reverted because of windows bots failing on
unittests. Change the current behavior to do not handle path traversals
on windows.
Handle ".", ".." and "./" with trailing slashes while collecting files
to be dumped into the vfs overlay directory.
Include the support for symlinks into components. Given the path:
/install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin"
component is a symlink, it's not safe to use `path::remove_dots` here,
and `realpath` is used to get the right answer. Since `realpath`
is expensive, we only do it at collecting time (which only happens
during the crash reproducer) and cache the base directory for fast lookups.
Overall, this makes the input to the VFS YAML file to be canonicalized
to never contain traversal components.
Differential Revision: http://reviews.llvm.org/D17104
rdar://problem/24499339
llvm-svn: 263617
btver1 is a SSSE3/SSE4a only CPU - it doesn't have AVX and doesn't support XSAVE.
Differential Revision: http://reviews.llvm.org/D17682
llvm-svn: 262772
Use it to calculate UserLabelPrefix, instead of specifying it (often
incorrectly).
Note that the *actual* user label prefix has always come from the
DataLayout, and is handled within LLVM. The main thing clang's
TargetInfo::UserLabelPrefix did was to set the #define value. Having
these be different from each-other is just silly.
Differential Revision: http://reviews.llvm.org/D17183
llvm-svn: 262737
SUMMARY:
This patch sets CPU string to its default value when it is not supplied by caller.
Reviewers: vkalintiris, dsanders
Subscribers: mohit.bhakkad, sagar, jaydeep, cfe-commits
Differential Revision: http://reviews.llvm.org/D16139
llvm-svn: 262691
The SafelyCloseFileDescriptor machinery does the right thing in the face
of signals while close will do something platform specific which results
in the FD potentially getting leaked.
llvm-svn: 262687
Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct.
User-defined reductions are defined as
#pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )]
These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The
combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will
denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting
combined value after executing the combiner.
As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause
will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier
omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced.
Differential Revision: http://reviews.llvm.org/D11182
llvm-svn: 262582
This behavior is enabled when the new CXTranslationUnit_KeepGoing
option is passed to clang_parseTranslationUnit{,2}. It is geared
towards use by IDEs and similar consumers of the clang-c API where
fatal errors may arise when parsing incomplete code mid-edit, or
when include paths are not properly configured yet. In such situations
one still wants to get as much information as possible about a TU.
Previously, the semantic analysis would not instantiate templates
or report additional fatal errors after the first fatal error was
encountered.
Fixes PR24268.
Patch by Milian Wolff.
llvm-svn: 262318
The VFS overlay mapping between virtual paths and real paths is done through
the 'external-contents' entries in YAML files, which contains hardcoded paths
to the real files.
When a module compilation crashes, headers are dumped into <name>.cache/vfs
directory and are mapped via the <name>.cache/vfs/vfs.yaml. The script
generated for reproduction uses -ivfsoverlay pointing to file to gather the
mapping between virtual paths and files inside <name>.cache/vfs. Currently, we
are only capable of reproducing such crashes in the same machine as they
happen, because of the hardcoded paths in 'external-contents'.
To be able to reproduce a crash in another machine, this patch introduces a new
option in the VFS yaml file called 'overlay-relative'. When it's equal to
'true' it means that the provided path to the YAML file through the
-ivfsoverlay option should also be used to prefix the final path for every
'external-contents'.
Example, given the invocation snippet "... -ivfsoverlay
<name>.cache/vfs/vfs.yaml" and the following entry in the yaml file:
"overlay-relative": "true",
"roots": [
...
"type": "directory",
"name": "/usr/include",
"contents": [
{
"type": "file",
"name": "stdio.h",
"external-contents": "/usr/include/stdio.h"
},
...
Here, a file manager request for virtual "/usr/include/stdio.h", that will map
into real path "/<absolute_path_to>/<name>.cache/vfs/usr/include/stdio.h.
This is a useful feature for debugging module crashes in machines other than
the one where the error happened.
Differential Revision: http://reviews.llvm.org/D17457
rdar://problem/24499339
llvm-svn: 261552
Handle ".", ".." and "./" with trailing slashes while collecting files
to be dumped into the vfs overlay directory.
Include the support for symlinks into components. Given the path:
/install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin"
component is a symlink, it's not safe to use `path::remove_dots` here,
and `realpath` is used to get the right answer. Since `realpath`
is expensive, we only do it at collecting time (which only happens
during the crash reproducer) and cache the base directory for fast lookups.
Overall, this makes the input to the VFS YAML file to be canonicalized
to never contain traversal components.
Differential Revision: http://reviews.llvm.org/D17104
rdar://problem/24499339
llvm-svn: 261551
option. Previously these options could both be used to specify that you were
compiling the implementation file of a module, with a different set of minor
bugs in each case.
This change removes -fmodule-implementation-of, and instead tracks a flag to
determine whether we're currently building a module. -fmodule-name now behaves
the same way that -fmodule-implementation-of previously did.
llvm-svn: 261372
The DataLayout can calculate alignment of vectors based on the alignment
of the element type and the number of elements. In fact, it is the product
of these two values. The problem is that for vectors of N x i1, this will
return the alignment of N bytes, since the alignment of i1 is 8 bits. The
vector types of vNi1 should be aligned to N bits instead. Provide explicit
alignment for HVX vectors to avoid such complications.
llvm-svn: 260680
Update the Preprocessor's VisibleModuleSet when typo-correction creates
an implicit module import so that we won't accidentally write an invalid
SourceLocation into the preamble AST. This would later lead to infinite
recursion when loading the preamble AST because we use the value in
ImportLocs to prevent visiting a module twice.
rdar://problem/24440990
llvm-svn: 260543
This allows ARMv8.2-A to be targeted either by using "armv8.2a" in the
triple, or by using -march=armv8.2-a (or the alias -march=armv8.2a).
The FP16 extension can be enabled with the "+fp16" suffix to the -march
or -mcpu option. This is consistent with the AArch64 option, rather than
the usual ARM option of -mfpu. We have agreed with the team which will
be upstreaming this to GCC that we want to use this new option format
for new architecture extensions for both ARM and AArch64.
Most of the work for this was done by the TargetParser patch in llvm.
Differential Revision: http://reviews.llvm.org/D15040
llvm-svn: 260533
Define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_[1248] macros on SystemZ.
This fixes a miscompile of GCC C++11 standard library headers
due to use of those macros in an ABI-changing manner.
See e.g. /usr/include/c++/4.8.5/ext/concurrence.h:
// Compile time constant that indicates prefered locking policy in
// the current configuration.
static const _Lock_policy __default_lock_policy =
#ifdef __GTHREADS
#if (defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2) \
&& defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4))
_S_atomic;
#else
_S_mutex;
#endif
#else
_S_single;
#endif
A different choice of __default_lock_policy causes different
sizes of several of the C++11 data structures, which are then
incompatible when inlined in clang-compiled code with what the
(GCC-compiled) external library expects.
This in turn leads to various crashes when using std::thread
in code compiled with clang, as see e.g. via the ThreadPool
unit tests. See PR 26473 for an example.
llvm-svn: 259931
name lookup information have changed since deserialization. For a C++ modules
build, we do not need to re-emit the identifier into the serialized identifier
table if only the name lookup information has changed (and in all cases, we
don't need to re-emit the macro information if only the name lookup information
has changed).
llvm-svn: 259901
Summary:
This patch adds parsing + sema for the target parallel for directive along with testcases.
Reviewers: ABataev
Differential Revision: http://reviews.llvm.org/D16759
llvm-svn: 259654
This patch adds the reserved operator ^^ when compiling for OpenCL (spec v1.1 s6.3.g),
which results in a more meaningful error message.
Patch by Neil Hickey!
Review: http://reviews.llvm.org/D13280
M test/SemaOpenCL/unsupported.cl
M include/clang/Basic/TokenKinds.def
M include/clang/Basic/DiagnosticParseKinds.td
M lib/Basic/OperatorPrecedence.cpp
M lib/Lex/Lexer.cpp
M lib/Parse/ParseExpr.cpp
llvm-svn: 259651
Defined the new AVX512 registers in clang inline asm.
Fixed a bug in the MC subtarget info creation during the parsing of MS asm statement - now it receives the actual CPU and target features information.
Differential Revision: http://reviews.llvm.org/D16757
llvm-svn: 259639
Summary:
This patch enhances Sema to check for the following restriction:
OpenMP 4.5 [2.17 Nesting of Regions]
If a target, target update, target data, target enter data, or
target exit data construct is encountered during execution of a
target region, the behavior is unspecified.
Reviewers: ABataev
Differential Revision: http://reviews.llvm.org/D16758
llvm-svn: 259464
Patch by H.J. Lu
```
typedef unsigned int gcc_word __attribute__((mode(word)));
```
and
```
typedef unsigned int gcc_unwind_word __attribute__((mode(unwind_word)));
```
define the largest unsigned integer types which can be stored in a
general purpose register, which may not be the pointer type. For x32,
they aren't pointer nor unsigned long. We should
1. Make getUnwindWordWidth and getRegisterWidth virtual,
2. Override them for x32, similar to hasInt128Type.
3. Use getRegisterWidth for __attribute__((mode(word)));
This fixes PR 24706.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D16779
llvm-svn: 259383
Summary:
This patch enhances Sema to check for the following restriction:
OpenMP 4.5 [2.17 Nesting of Regions]
If a target, target update, target data, target enter data, or
target exit data construct is encountered during execution of a
target region, the behavior is unspecified.
Reviewers: ABataev
Differential Revision: http://reviews.llvm.org/D16758
llvm-svn: 259366
Various bits we'd like to use the new ABI actually compile with "-arch armv7k
-miphoneos-version-min=9.0". Not ideal, but also not ridiculous given how
slices work.
llvm-svn: 258976
This reverts commit r258504.
This commit breaks (at least) sparc-rtems -- the OS (RTEMS) used to
override UserLabelPrefix to "", despite the arch (SPARC) having set it
to "_". Now, the OS doesn't override anymore, but the arch sets it to
"_", resulting in the wrong value. I expect this probably breaks other
OSes that overrode to "" before, as well. (Clearly we have some missing
test cases, here...)
llvm-svn: 258894
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"This is the way [autoconf] ends
Not with a bang but a whimper."
-T.S. Eliot
Reviewers: chandlerc, grosbach, bob.wilson, echristo
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D16472
llvm-svn: 258862
Summary:
This patch adds parsing + sema for the target parallel directive and its clauses along with testcases.
Reviewers: ABataev
Differential Revision: http://reviews.llvm.org/D16553
Rebased to current trunk and updated test cases.
llvm-svn: 258832
Summary:
This patch adds parsing + sema for the defaultmap clause associated with the target directive (among others).
Reviewers: ABataev
Differential Revision: http://reviews.llvm.org/D16527
llvm-svn: 258817
Fix arc patch fuzz error.
Summary:
Support for the pipe built-in functions for OpenCL 2.0.
The pipe builtin functions may have infinite kinds of element types, one approach
would be to just generate calls that would always use generic types such as void*.
This patch is based on bader's opencl support patch on SPIR-V branch.
Reviewers: Anastasia, pekka.jaaskelainen
Subscribers: keryell, bader, cfe-commits
Differential Revision: http://reviews.llvm.org/D15914
llvm-svn: 258782
Summary:
Support for the pipe built-in functions for OpenCL 2.0.
The pipe builtin functions may have infinite kinds of element types, one approach
would be to just generate calls that would always use generic types such as void*.
This patch is based on bader's opencl support patch on SPIR-V branch.
Reviewers: Anastasia, pekka.jaaskelainen
Subscribers: keryell, bader, cfe-commits
Differential Revision: http://reviews.llvm.org/D15914
llvm-svn: 258773
FixedCompilationDatabase sets the working dir to "." by default. For
chdir(".") this is a noop but this lead to InMemoryFileSystem to create
bogus paths. Fixes PR25327.
llvm-svn: 257260
OpenMP 4.0-3.1 supports the next format of ‘schedule’ clause: schedule(kind[, chunk_size])
Where kind can be one of ‘static’, ‘dynamic’, ‘guided’, ‘auto’ or ‘runtime’.
OpenMP 4.5 defines the format: schedule([modifier [, modifier]:]kind[, chunk_size])
Modifier can be one of ‘monotonic’, ‘nonmonotonic’ or ‘simd’.
llvm-svn: 256487
It resolves clang selfhosting with std::once() for Cygwin.
FIXME: It may be EmulatedTLS-generic also for X86-Android.
FIXME: Pass EmulatedTLS to LLVM CodeGen from Clang with -femulated-tls.
llvm-svn: 256134
- Removed support for hexagonv3 and earlier.
- Added handling of hexagonv55 and hexagonv60.
- Added handling of target features (hvx, hvx-double).
- Updated paths to reflect current directory layout.
llvm-svn: 255502
Make RedirectedFileSystem::openFilForRead(path)->status() the same as
RedirectedFileSystem::status(path). Previously we would just get the
status of the underlying real file, which would not have the IsVFSMapped
bit set.
This fixes rebuilding a module that has an include that is relative to
the includer where we will lookup the real path of that file before we
lookup the VFS location.
rdar://problem/23640339
llvm-svn: 255312
OpenMP 4.5 adds directives 'taskloop' and 'taskloop simd'. These directives support clause 'num_tasks'. Patch adds parsing/semantic analysis for this clause.
llvm-svn: 255008
OpenMP 4.5 adds 'taksloop' and 'taskloop simd' directives, which have 'grainsize' clause. Patch adds parsing/sema analysis of this clause.
llvm-svn: 254903
OpenMP 4.5 adds 'taskloop' and 'taskloop simd' directives. These directives have new 'nogroup' clause. Patch adds basic parsing/sema support for this clause.
llvm-svn: 254899
OpenMP 4.5 defines new clause 'priority' for 'task', 'taskloop' and 'taskloop simd' directives. Added parsing and sema analysis for 'priority' clause in 'task' and 'taskloop' directives.
llvm-svn: 254398
Add/Subtract.
The following instructions are added to AArch32 instruction set:
- VQRDMLAH: Vector Saturating Rounding Doubling Multiply Accumulate
Returning High Half
- VQRDMLSH: Vector Saturating Rounding Doubling Multiply Subtract
Returning High Half
The following instructions are added to AArch64 instruction set:
- SQRDMLAH: Signed Saturating Rounding Doubling Multiply Accumulate
Returning High Half
- SQRDMLSH: Signed Saturating Rounding Doubling Multiply Subtract
Returning High Half
This patch adds intrinsic and ACLE macro support for these instructions,
as well as corresponding tests.
Differential Revision: http://reviews.llvm.org/D14982
llvm-svn: 254250
I spotted this by inspection in the for loop that wasn't using its iterator and was just acting on the current state repeatedly.
This appears to have been introduced as a copy and paste bug in r140763 over 4 years ago.
I have no idea how to test this. I just went back to the original commit and tried to use the variables it was using before that.
llvm-svn: 254134
than reusing the "overridden buffer" mechanism. This will allow us to make
embedded files and overridden files behave differently in future.
llvm-svn: 254121
For MCU only C calling convention is allowed, all other calling conventions are not supported.
Differential Revision: http://reviews.llvm.org/D14864
llvm-svn: 254063
This flag causes all files that were read by the compilation to be embedded
into a produced module file. This is useful for distributed build systems that
use an include scanning system to determine which files are "needed" by a
compilation, and only provide those files to remote compilation workers. Since
using a module can require any file that is part of that module (or anything it
transitively includes), files that are not found by an include scanner can be
required in a regular build using explicit modules. With this flag, only files
that are actually referenced by transitively-#included files are required to be
present on the build machine.
llvm-svn: 253950
Summary: 's' is used to specify sgprs and 'v' is used to specify vgprs.
Reviewers: arsenm, echristo
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D14307
llvm-svn: 253610
Currently, when there is a global register variable in a program that
is bound to an invalid register, clang/llvm prints an error message that
is not very user-friendly.
This commit improves the diagnostic and moves the check that used to be
in the backend to Sema. In addition, it makes changes to error out if
the size of the register doesn't match the declared variable size.
e.g., volatile register int B asm ("rbp");
rdar://problem/23084219
Differential Revision: http://reviews.llvm.org/D13834
llvm-svn: 253405
The TargetParser API to get the default FPU and default extensions has
changed so that it can fall back to the architecture in case of a
generic CPU.
llvm-svn: 253199
is not defined for 32bit mode, but __sparcv9 is. Pass down the correct
-target-cpu flags to the backend, so that instruction restrictions are
applied correctly. Pass down the correct -A flag when not using IAS.
The latter is limited to NetBSD targets in this commit.
llvm-svn: 252545
This patch fixes one more thing in MCU psABI support: LongDoubleWidth should be set to 64.
Differential Revision: http://reviews.llvm.org/D14285
llvm-svn: 252156
we can't load that file due to a configuration mismatch, and implicit module
building is disabled, and the user turns off the error-by-default warning for
that situation, then fall back to textual inclusion for the module rather than
giving an error if any of its headers are included.
llvm-svn: 252114
This patch implements two things in front-end for MCU psABI support:
1) "long double type is the same as double."
2) "New predefined C/C++ pre-processor symbols: iamcu and iamcu__.
Differential Revision: http://reviews.llvm.org/D14205
llvm-svn: 251786
This sets the mostly expected Darwin default ABI options for these two
platforms. Active changes from these defaults for watchOS are in a later patch.
llvm-svn: 251708
GCC uses the x87DoubleExtended model for long doubles, and passes them
indirectly by address through function calls.
Also replace the existing mingw-long-double assembly emitting test with
an IR-level test.
llvm-svn: 251567
Previously, __weak was silently accepted and ignored in MRC mode.
That makes this a potentially source-breaking change that we have to
roll out cautiously. Accordingly, for the time being, actual support
for __weak references in MRC is experimental, and the compiler will
reject attempts to actually form such references. The intent is to
eventually enable the feature by default in all non-GC modes.
(It is, of course, incompatible with ObjC GC's interpretation of
__weak.)
If you like, you can enable this feature with
-Xclang -fobjc-weak
but like any -Xclang option, this option may be removed at any point,
e.g. if/when it is eventually enabled by default.
This patch also enables the use of the ARC __unsafe_unretained qualifier
in MRC. Unlike __weak, this is being enabled immediately. Since
variables are essentially __unsafe_unretained by default in MRC,
the only practical uses are (1) communication and (2) changing the
default behavior of by-value block capture.
As an implementation matter, this means that the ObjC ownership
qualifiers may appear in any ObjC language mode, and so this patch
removes a number of checks for getLangOpts().ObjCAutoRefCount
that were guarding the processing of these qualifiers. I don't
expect this to be a significant drain on performance; it may even
be faster to just check for these qualifiers directly on a type
(since it's probably in a register anyway) than to do N dependent
loads to grab the LangOptions.
rdar://9674298
llvm-svn: 251041
The logic for parsing FP capabilities to set __ARM_FP was mistakenly removing
the Half-Precision capability when handling fp-only-sp resulting in a value
of 0x4. Section 6.5.1 of ACLE states that for such FP architectures the value
should be 0x6
llvm-svn: 250888
Summary: It breaks the build for the ASTMatchers
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D13893
llvm-svn: 250827
If you increase the number of diags of a particular type by one more than the
number available you get the nice assert message. If you do it by two more
than available you get the old non-helpful message. Combining the two makes
sense I think.
llvm-svn: 250546
This is a more principled version of what I did earlier. Path
normalization is generally a good thing, but may break users in strange
environments, e. g. using lots of symlinks. Let the user choose and
default it to on.
This also changes adding a duplicated file into returning an error if
the file contents are different instead of an assertion failure.
Differential Revision: http://reviews.llvm.org/D13658
llvm-svn: 250060
Actually the only special path we have to handle is ./foo, the rest is
tricky to get right so do the same thing as the existing YAML vfs here.
llvm-svn: 250036
This can fail badly if we're overlaying a real file system and there are
symlinks there. Just keep the path as-is for now.
This essentially reverts r249830.
llvm-svn: 250021
Rationale :
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This is a preparatory patch to the actual diagnosis code which is
coming in a future patch. This sets us up to have the correct information
where we need it and verifies that it's being emitted for the backend
to handle.
llvm-svn: 249733
that we can build up an accurate set of features rather than relying on
TargetInfo initialization via handleTargetFeatures to munge the list
of features.
llvm-svn: 249732
Simplifying the convoluted CPU handling in ARMTargetInfo.
The default base CPU on ARM is ARM7TDMI, arch ARMv4T, and
ARMTargetInfo had a different one. This wasn't visible from
Clang because the driver selects the defaults and sets the
Arch/CPU features directly, but the constructor depended
on the CPU, which was never used.
This patch corrects the mistake and greatly simplifies
how CPU is dealt with (essentially by removing the duplicated
DefaultCPU field).
Tests updated.
llvm-svn: 249699
- Rename it to RedirectingFileSystem. This is what it does, YAML is just a
serialization format for it.
- Consistently use unique_ptr for memory management.
No functional change intended.
llvm-svn: 249532
Apart from being cleaner this also means that clang-format no longer has
access to the host file system. This isn't necessary because clang-format
never reads includes :)
Includes minor tweaks and bugfixes found in the VFS implementation while
running clang-format tests.
llvm-svn: 249385
For RealFileSystem this is getcwd()/chdir(), the synthetic file systems can
make up one for themselves. OverlayFileSystem now synchronizes the working
directories when a new FS is added to the overlay or the overlay working
directory is set. This allows purely artificial file systems that have zero
ties to the underlying disks.
Differential Revision: http://reviews.llvm.org/D13430
llvm-svn: 249316
This is a simple file system tree of memory buffers that can be filled by a
client. In conjunction with an OverlayFS it can be used to make virtual
files accessible right next to physical files. This can be used as a
replacement for the virtual file handling in FileManager and which I intend
to remove eventually.
llvm-svn: 249315
In versions of clang prior to r238238, __declspec was recognized as a keyword in
all modes. It was then changed to only be enabled when Microsoft or Borland
extensions were enabled (and for CUDA, as a temporary measure). There is a
desire to support __declspec in Playstation code, and possibly other
environments. This commit adds a command-line switch to allow explicit
enabling/disabling of the recognition of __declspec as a keyword. Recognition
is enabled by default in Microsoft, Borland, CUDA, and PS4 environments, and
disabled in all other environments.
Patch by Warren Ristow!
llvm-svn: 249279
All global variables that are not enclosed in a declare target region
must be captured in the target region as local variables do. Currently,
there is no support for declare target, so this patch adds support for
capturing all the global variables used in a the target region.
llvm-svn: 249154
We support all __sync_val_compare_and_swap_* builtins (only 64-bit on 64-bit
targets) on all cores, and should define the corresponding
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_* macros, just as GCC does. As it turns out,
this is really important because they're needed to prevent a bad ODR violation
with libstdc++'s std::shared_ptr (this is well explained in PR12730).
We were doing this only for P8, but this is necessary on all PPC systems.
llvm-svn: 249009
Currently it's 64-bit which will lead to mismatch between host and
device code if we compile for i386.
Differential Revision: http://reviews.llvm.org/D13181
llvm-svn: 248753
Parsing and sema analysis for 'simd' clause in 'ordered' directive.
Description
If the simd clause is specified, the ordered regions encountered by any thread will use only a single SIMD lane to execute the ordered
regions in the order of the loop iterations.
Restrictions
An ordered construct with the simd clause is the only OpenMP construct that can appear in the simd region
llvm-svn: 248696
OpenMP 4.1 extends format of '#pragma omp ordered'. It adds 3 additional clauses: 'threads', 'simd' and 'depend'.
If no clause is specified, the ordered construct behaves as if the threads clause had been specified. If the threads clause is specified, the threads in the team executing the loop region execute ordered regions sequentially in the order of the loop iterations.
The loop region to which an ordered region without any clause or with a threads clause binds must have an ordered clause without the parameter specified on the corresponding loop directive.
llvm-svn: 248569
Currently, the availability of DSP instructions (ACLE 6.4.7) is handled in
a hand-rolled tricky condition block in lib/Basic/Targets.cpp, with a FIXME:
attached.
http://reviews.llvm.org/D12937 moved the handling of the DSP feature over to
ARMTargetParser.def in LLVM, to be in line with other architecture extensions.
This is the corresponding patch to clang, to clear the FIXME: and update
the tests.
Differential Revision: http://reviews.llvm.org/D12938
llvm-svn: 248521
Trace the ranges through the macro backtrace better. This allows better
range highlighting through all levels of the macro bracktrace. Also some
improvements to backtrace printer for omitting different backtraces.
Patch by Zhengkai Wu.
Differential Revision: http://reviews.llvm.org/D12379
llvm-svn: 248454
* adds -aux-triple option to specify target triple
* propagates aux target info to AST context and Preprocessor
* pulls in target specific preprocessor macros.
* pulls in target-specific builtins from aux target.
* sets appropriate host or device attribute on builtins.
Differential Revision: http://reviews.llvm.org/D12917
llvm-svn: 248299
Currently, the availability of DSP instructions (ACLE 6.4.7) is handled in
a hand-rolled tricky condition block in lib/Basic/Targets.cpp, with a FIXME:
attached.
http://reviews.llvm.org/D12937 moved the handling of +t2dsp over to
ARMTargetParser.def in LLVM, to be in line with other architecture extensions.
This is the corresponding patch to clang, to clear the FIXME: and update
the tests.
Differential Revision: http://reviews.llvm.org/D12938
llvm-svn: 248154
Summary:
This change adds support for `__builtin_ms_va_list`, a GCC extension for
variadic `ms_abi` functions. The existing `__builtin_va_list` support is
inadequate for this because `va_list` is defined differently in the Win64
ABI vs. the System V/AMD64 ABI.
Depends on D1622.
Reviewers: rsmith, rnk, rjmccall
CC: cfe-commits
Differential Revision: http://reviews.llvm.org/D1623
llvm-svn: 247941
WebAssembly's spec has now been updated to specify some guarantees
about lock free atomic accesses. Update clang to match.
This also updates sig_atomic_t to be 64-bit on wasm64. WebAssembly
does not presently have asynchronous interrupts, but this change is
within the spirit of how they will work if they are added.
Differential Revision: http://reviews.llvm.org/D12862
llvm-svn: 247624
This makes int_fast64_t and int_least64_t the same type as int64_t, and
eliminates a difference between wasm32 and wasm64.
Differential Revision: http://reviews.llvm.org/D12861
llvm-svn: 247622
Seems it broke the Polly build.
From http://lab.llvm.org:8011/builders/perf-x86_64-penryn-O3-polly-fast/builds/11687/steps/compile/logs/stdio:
In file included from /home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.src/lib/TableGen/Record.cpp:14:0:
/home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.src/include/llvm/TableGen/Record.h:369:3: error: looser throw specifier for 'virtual llvm::TypedInit::~TypedInit()'
/home/grosser/buildslave/perf-x86_64-penryn-O3-polly-fast/llvm.src/include/llvm/TableGen/Record.h:270:11: error: overriding 'virtual llvm::Init::~Init() noexcept (true)'
llvm-svn: 247222
This implements basic support for compiling (though not yet assembling
or linking) for a WebAssembly target. Note that ABI details are not yet
finalized, and may change.
Differential Revision: http://reviews.llvm.org/D12002
llvm-svn: 246814
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246764
Original commit message:
[ARM] Allow passing/returning of __fp16 arguments
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246760
The ACLE (ARM C Language Extensions) 2.0 allows the __fp16 type to be
used as a functon argument or return type (ACLE 1.1 did not).
The current public release of the AAPCS (2.09) states that __fp16 values
should be converted to single-precision before being passed or returned,
but AAPCS 2.10 (to be released shortly) changes this, so that they are
passed in the least-significant 16 bits of either a GPR (for base AAPCS)
or a single-precision register (for AAPCS-VFP). This does not change how
arguments are passed if they get passed on the stack.
This patch brings clang up to compliance with the latest versions of
both of these specs.
We can now set the __ARM_FP16_ARGS ACLE predefine, and we have always
been able to set the __ARM_FP16_FORMAT_IEEE predefine (we do not support
the alternative format).
llvm-svn: 246755
Also:
- Add a typedef to make working with the result easier.
- Update callers to use the new function.
- Make initFeatureMap out of line.
llvm-svn: 246468
const char pointers. In turn, push this through Clang APIs as well,
simplifying a number of bits of code that was handling the oddities of
nullptrs.
llvm-svn: 246375
Without this, 64-byte vector types (__m512), specified to be 64-byte
aligned in the AVX512 draft SysV ABI, will only be 32-byte aligned.
This is analoguous to AVX, for which we accept 32-byte max alignment.
Differential Revision: http://reviews.llvm.org/D10724
llvm-svn: 246230
There's no point in using a larger alignment if we have no instructions
that would benefit from it.
Differential Revision: http://reviews.llvm.org/D12389
llvm-svn: 246229
The ABI string only exists to communicate with TargetCodeGenInfo.
Concretely, since we only used "avx*" ABI strings on x86_64 (as AVX
doesn't affect the i386 ABIs), this meant that, when initializing
SimdDefaultAlign, we would ignore AVX/AVX512 on i386, for no good
reason.
Instead, directly check the features. A similar change for
MaxVectorAlign will follow.
Differential Revision: http://reviews.llvm.org/D12390
llvm-svn: 246228
with multiple uses of feature map construction.
Note: We could make this a static function on TargetInfo if we
fix the x86 port needing to check the triple in an isolated case.
llvm-svn: 246128
This involved specializing handleUserFeatures so that we could perform
diagnostics on -only- user supplied features and migrating the rest of
the initialization functions to set features based on enabling and disabling
full feature sets. No functional change intended.
llvm-svn: 245936
The ACLE (ARM C Language Extensions) 2.0 defines that the predefined macro
__ARM_FP16_ARGS should be defined if __fp16 can be used as an argument and
result.
The support for __fp16 to be used as an argument and result is already
implemented for AArch64 so this change is just adding the missing macro.
Differential Revision: http://reviews.llvm.org/D12240
llvm-svn: 245833
Add parsing/sema analysis for 'simdlen' clause in simd directives. Also add check that if both 'safelen' and 'simdlen' clauses are specified, the value of 'simdlen' parameter is less than the value of 'safelen' parameter.
llvm-svn: 245692
OpenMP 4.1 adds 3 optional modifiers to 'linear' clause.
Format of 'linear' clause has changed to:
```
linear(linear-list[ : linear-step])
```
where linear-list is one of the following
```
list
modifier(list)
```
where modifier is one of the following:
```
ref (C++)
val (C/C++)
uval (C++)
```
Patch adds parsing and sema analysis for these modifiers.
llvm-svn: 245550
"generic" cpu was wrongly handled as exact real CPU name of ARMv8.1A architecture.
This has been fixed, now it is abstract name, suitable for any arch.
Reviewers: rengolin
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11640
llvm-svn: 245445
Summary:
MSDN says that fastcall, stdcall, thiscall, and vectorcall are all
accepted but ignored on ARM and X64.
https://msdn.microsoft.com/en-us/library/984x0h58.aspx
MSDN also says cdecl is also accepted and typically ignored
This patch brings ARM in line with how we ignore them for X64
Reviewers: rnk
Subscribers: compnerd, cfe-commits
Differential Revision: http://reviews.llvm.org/D12034
llvm-svn: 245076
file in the .pcm files. This allows a smaller set of files to be sent to a
remote build worker when building with explicit modules (for instance, module
map files need not be sent along with the corresponding precompiled modules).
This doesn't actually make the embedded files visible to header search, so
it's not useful as a packaging format for public header files.
llvm-svn: 245028
This preserves backwards compatibility for two hacks in the Darwin
system module map files:
1. The use of 'requires excluded' to make headers non-modular, which
should really be mapped to 'textual' now that we have this feature.
2. Silently removes a bogus cplusplus requirement from IOKit.avc.
Once we start diagnosing missing requirements and headers on
auto-imports these would have broken compatibility with existing Darwin
SDKs.
llvm-svn: 244912
... and add aarch32 to specifically refer to the 32-bit ones.
Previously, 'arm' meant only 32-bit architectures and there was no way
for a module to build with both 32 and 64 bit ARM architectures.
Now a module that is intended to work on both architectures can specify
requires arm
whereas a module only for 32-bit platforms can say
requires aarch32
and just like before, 64-bit only can say
requires aarch64
llvm-svn: 244306
Eric Christopher