| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
features
llvm-svn: 190702
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
address spaces which is both (1) a "semantic" concept and
(2) possibly a hardware level restriction. It is desirable to
be able to discard/merge the LLVM-level address spaces on arguments for which
there is no difference to the current backend while keeping
track of the semantic address spaces in a funciton prototype. To do this
enable addition of the address space into the name-mangling process. Add
some tests to document this behaviour against inadvertent changes.
Patch by Michele Scandale!
llvm-svn: 190684
|
| |
|
|
| |
llvm-svn: 190496
|
| |
|
|
| |
llvm-svn: 190394
|
| |
|
|
|
|
|
| |
Enabling sse4.2 will implicitly enable popcnt unless popcnt is explicitly disabled.
Disabling sse4.2 will not disable popcnt if popcnt is explicitly enabled.
llvm-svn: 190387
|
| |
|
|
| |
llvm-svn: 190051
|
| |
|
|
|
|
|
|
|
| |
As a result, Clang doesn't define the pre-processor macros that are expected
on this platform.
Thanks to Robert Millan for the patch
llvm-svn: 190048
|
| |
|
|
| |
llvm-svn: 189670
|
| |
|
|
|
|
| |
Based on a patch by Benno Rice!
llvm-svn: 189644
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Makes functions with implicit calling convention compatible with
function types with a matching explicit calling convention. This fixes
things like calls to qsort(), which has an explicit __cdecl attribute on
the comparator in Windows headers.
Clang will now infer the calling convention from the declarator. There
are two cases when the CC must be adjusted during redeclaration:
1. When defining a non-inline static method.
2. When redeclaring a function with an implicit or mismatched
convention.
Fixes PR13457, and allows clang to compile CommandLine.cpp for the
Microsoft C++ ABI.
Excellent test cases provided by Alexander Zinenko!
Reviewers: rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D1231
llvm-svn: 189412
|
| |
|
|
| |
llvm-svn: 189302
|
| |
|
|
| |
llvm-svn: 189142
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original idea was to implement it all on the driver, but to do that the
driver needs to know the sse level and to do that it has to know the default
features of a cpu.
Benjamin Kramer pointed out that if one day we decide to implement support for
' __attribute__ ((__target__ ("arch=core2")))', then the frontend needs to
keep its knowledge of default features of a cpu.
To avoid duplicating which part of clang handles default cpu features,
it is probably better to handle -mfpmath in the frontend.
For ARM this patch is just a small improvement. Instead of a cpu list, we
check if neon is enabled, which allows us to reject things like
-mcpu=cortex-a9 -mfpu=vfp -mfpmath=neon
For X86, since LLVM doesn't support an independent ssefp feature, we just
make sure the selected -mfpmath matches the sse level.
llvm-svn: 188939
|
| |
|
|
|
|
|
| |
setFeatureEnabled is never called with "32" or "64". The driver never passes it
and mips' getDefaultFeatures sets the Features map directly.
llvm-svn: 188913
|
| |
|
|
|
|
|
| |
This is a partial revert of r188817 now that the driver handles -target-feature
in a single place.
llvm-svn: 188910
|
| |
|
|
|
|
| |
Thanks for Craig Topper for noticing it.
llvm-svn: 188902
|
| |
|
|
| |
llvm-svn: 188867
|
| |
|
|
|
|
| |
to be using.
llvm-svn: 188860
|
| |
|
|
|
|
|
|
|
| |
This moves the logic for handling -mfoo -mno-foo from the driver to -cc1. It
also changes -cc1 to apply the options in order, fixing pr16943.
The handling of -mno-mmx -msse is now an explicit special case.
llvm-svn: 188817
|
| |
|
|
|
|
|
| |
The driver validates its options, so we don't need to redo the work in
"clang -cc1".
llvm-svn: 188806
|
| |
|
|
| |
llvm-svn: 188802
|
| |
|
|
|
|
|
| |
This removes the very long chains of
Feature["avx"] = Feature["sse42"] = ... = true;
llvm-svn: 188799
|
| |
|
|
| |
llvm-svn: 188762
|
| |
|
|
| |
llvm-svn: 188758
|
| |
|
|
| |
llvm-svn: 188757
|
| |
|
|
| |
llvm-svn: 188756
|
| |
|
|
|
|
|
|
|
| |
The previous value was set to match some ancient version of Apple's GCC.
The value should be higher than anything used by Apple's GCC, but we don't
intend for this value to be updated in the future. We have other macros to
identify compiler versions. <rdar://problem/14749599>
llvm-svn: 188700
|
| |
|
|
| |
llvm-svn: 188258
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch adds -mmsa and -mno-msa to the options supported by
clang to enable and disable support for MSA.
When MSA is enabled, a predefined macro '__mips_msa' is defined to 1.
Patch by Daniel Sanders
llvm-svn: 188184
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Ana Pazos
- Completed implementation of instruction formats:
AdvSIMD three same
AdvSIMD modified immediate
AdvSIMD scalar pairwise
- Completed implementation of instruction classes
(some of the instructions in these classes
belong to yet unfinished instruction formats):
Vector Arithmetic
Vector Immediate
Vector Pairwise Arithmetic
- Initial implementation of instruction formats:
AdvSIMD scalar two-reg misc
AdvSIMD scalar three same
- Intial implementation of instruction class:
Scalar Arithmetic
- Initial clang changes to support arm v8 intrinsics.
Note: no clang changes for scalar intrinsics function name mangling yet.
- Comprehensive test cases for added instructions
To verify auto codegen, encoding, decoding, diagnosis, intrinsics.
llvm-svn: 187568
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch provides basic support for powerpc64le as an LLVM target.
However, use of this target will not actually generate little-endian
code. Instead, use of the target will cause the correct little-endian
built-in defines to be generated, so that code that tests for
__LITTLE_ENDIAN__, for example, will be correctly parsed for
syntax-only testing. Code generation will otherwise be the same as
powerpc64 (big-endian), for now.
The patch leaves open the possibility of creating a little-endian
PowerPC64 back end, but there is no immediate intent to create such a
thing.
The new test case variant ensures that correct built-in defines for
little-endian code are generated.
llvm-svn: 187180
|
| |
|
|
|
|
| |
Approval in here http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064169.html
llvm-svn: 187143
|
| |
|
|
| |
llvm-svn: 186694
|
| |
|
|
|
|
| |
Long double is 64 bits on FreeBSD PPC, so the f128 entry is superfluous.
llvm-svn: 185582
|
| |
|
|
|
|
| |
It's not the case on ie. FreeBSD.
llvm-svn: 185572
|
| |
|
|
|
|
| |
Patch by Job Noorman!
llvm-svn: 185362
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 185261
|
| |
|
|
| |
llvm-svn: 185075
|
| |
|
|
| |
llvm-svn: 184970
|
| |
|
|
|
|
|
|
| |
this code. These aren't technically standard predefines for the platform
but apparantly lots of folks use them as they show up within LLVM's own
codebase. ;] This may even fix some self host issues w/ the JIT!!!
llvm-svn: 184830
|
| |
|
|
| |
llvm-svn: 184578
|
| |
|
|
|
|
|
|
| |
Some embedded targets use ARM's AAPCS with iOS header files that define size_t
as unsigned long, which conflicts with the usual AAPCS definition of size_t
as unsigned int.
llvm-svn: 184171
|
| |
|
|
| |
llvm-svn: 184113
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Just like on Linux, FreeBSD/armv6 assumes the system supports
ldrex/strex unconditionally. It is also used by the kernel. We can
therefore enable support for it, like we do on Linux.
While there, change one of the unit tests to explicitly test against
armv5 instead of armv7, as it actually tests whether libcalls are
emitted.
llvm-svn: 184040
|
| |
|
|
|
|
|
|
|
| |
We're getting reports of this warning getting triggered in cases where it
is not adding any value. There is no asm operand modifier that you can use
to silence it, and there's really nothing wrong with having an LDRB, for
example, with a "char" output.
llvm-svn: 183172
|
| |
|
|
|
|
| |
Other operating systems, including FreeBSD and NetBSD, use long.
llvm-svn: 182215
|
| |
|
|
| |
llvm-svn: 182029
|
| |
|
|
|
|
| |
It's an LP64 platform.
llvm-svn: 181867
|
| |
|
|
|
|
|
| |
This matches gcc's behaviour. The patch also explicitly parses the version so
that this keeps working when we add support for v8.
llvm-svn: 181750
|
| |
|
|
|
|
|
|
|
| |
This is safe given how the pre-v6 atomic ops funcions in libgcc are
implemented.
This fixes pr15429.
llvm-svn: 181728
|