| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 167735
|
|
|
|
|
|
|
|
|
| |
The 'a', 'c', and 'd' constraints on i386 mean a 32-bit register. We cannot
place a 64-bit value into the 32-bit register. Error out instead of causing the
compiler to spew general badness.
<rdar://problem/12415959>
llvm-svn: 167717
|
|
|
|
|
|
|
|
|
|
|
|
| |
- New options '-mrtm'/'-mno-rtm' are added to enable/disable RTM feature
- Builtin macro '__RTM__' is defined if RTM feature is enabled
- RTM intrinsic header is added and introduces 3 new intrinsics, namely
'_xbegin', '_xend', and '_xabort'.
- 3 new builtins are added to keep compatible with gcc, namely
'__builtin_ia32_xbegin', '__builtin_ia32_xend', and '__builtin_ia32_xabort'.
- Test cases for pre-defined macro and new intrinsic codegen are added.
llvm-svn: 167665
|
|
|
|
|
|
|
|
|
|
|
| |
Haiku does not support this (yet). Leaving it set to true leads to
configure scripts detecting __thread being available and Clang emitting
code for it, resulting in binaries the runtime_loader will refuse to
load.
Patch by Jonathan Schleifer!
llvm-svn: 167576
|
|
|
|
|
|
| |
*Sanitizer to Sanitize* in preparation for later patches.
llvm-svn: 167405
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ELF subtarget.
The existing description string is moved from PPC64TargetInfo to its
DarwinTargetInfo subclass, to avoid any changes to the Darwin ABI.
PPC64TargetInfo now has two possible description strings: one for FreeBSD,
which requires 8-byte alignment, and a default string that requires
16-byte alignment.
I've added a test for PPC64 Linux to verify the 16-byte alignment. If
somebody wants to add a separate test for FreeBSD, that would be great.
Note that there is a companion patch to update the alignment information
in LLVM, which I am committing now as well.
llvm-svn: 166927
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code checks the ASM string to see if the output size is able to fit within
the variable specified as the output. For instance, scalar-to-vector conversions
may not really work. It's on by default, but can be turned off with a flag if
you think you know what you're doing.
This is placed under a flag ('-Wasm-operand-widths') and flag group ('-Wasm').
<rdar://problem/12284092>
llvm-svn: 166737
|
|
|
|
|
|
|
|
| |
variables when using a gnueabihf or aapcs-vfp target.
Tested by me and Wei-Ren Chen.
llvm-svn: 166679
|
|
|
|
| |
llvm-svn: 166655
|
|
|
|
|
|
|
| |
modifiers. (From an idea by Eric...)
<rdar://problem/12284092>
llvm-svn: 166647
|
|
|
|
| |
llvm-svn: 166431
|
|
|
|
| |
llvm-svn: 166430
|
|
|
|
|
|
|
| |
target options around so they can be accessed at any point (rather
than keeping them transient).
llvm-svn: 166072
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because PNaCl bitcode must be target-independent, it uses some
different bitcode representations from other targets (e.g. byval and
sret for structures). This means that without additional type
information, it cannot meet some native ABI requirements for some
targets (e.g. passing structures containing unions by value on
x86-64). To allow generation of code which uses the correct native
ABIs, we also support triples such as x86_64-nacl, which uses
target-dependent IR (as opposed to le32-nacl, which uses byval and
sret).
To allow interoperation between the two types of code, this patch adds
a calling convention attribute to be used in code compiled with the
target-dependent triple, which will generate code using the le32-style
bitcode. This calling convention does not need to be explicitly
supported in the backend because it determines bitcode representation
rather than native conventions (the backend just needs to undersand
how to handle byval and sret for the Native Client OS).
This patch implements __attribute__((pnaclcall)) to generate calls in
bitcode according to the le32 bitcode conventions, an attribute which
is accepted by any Native Client target, but issues a warning
otherwise.
llvm-svn: 166065
|
|
|
|
|
|
| |
created.
llvm-svn: 165943
|
|
|
|
|
|
| |
Patch by Tom Stellard.
llvm-svn: 165850
|
|
|
|
|
|
| |
with x86/ARM architecture
llvm-svn: 165722
|
|
|
|
|
|
| |
and Native Client
llvm-svn: 165715
|
|
|
|
|
|
|
|
|
| |
Support the following intrinsics:
_mm_cvtph_ps, _mm256_cvtph_ps, _mm_cvtps_ph, _mm256_cvtps_ph
rdar://12407875
llvm-svn: 165685
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AAPCS ABI Section 7.1.4 [1] specifies that va_list
should be defined as struct __va_list { void *__ap;};
And in C++, it is defined in namespace std.
[1] http://infocenter.arm.com/help/topic
/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf
Patch by Weiming Zhao.
llvm-svn: 165609
|
|
|
|
|
|
|
|
| |
is allowed or ignored with warning. This allows for correct name mangling for x64 targets on Windows, which in turn allows for linking against the Win32 APIs.
Fixes PR13782
llvm-svn: 165015
|
|
|
|
| |
llvm-svn: 164906
|
|
|
|
| |
llvm-svn: 164905
|
|
|
|
|
|
| |
ASan doesn't play well with -D_FORTIFY_SOURCE, which is enabled by default starting at OS X 10.7
llvm-svn: 164299
|
|
|
|
|
|
| |
Patch by Tobias von Koch!
llvm-svn: 164176
|
|
|
|
| |
llvm-svn: 163804
|
|
|
|
| |
llvm-svn: 163465
|
|
|
|
| |
llvm-svn: 163464
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of the code guarded with ANDROIDEABI are not
ARM-specific, and having no relation with arm-eabi.
Thus, it will be more natural to call this
environment "Android" instead of "ANDROIDEABI".
Note: We are not using ANDROID because several projects
are using "-DANDROID" as the conditional compilation
flag.
llvm-svn: 163088
|
|
|
|
|
|
| |
The patch suggested by Brad Smith.
llvm-svn: 162858
|
|
|
|
|
|
|
| |
to define all macros for MIPS targets. Remove redundant virtual function
getArchDefines(). Two virtual functions for this task are really too much.
llvm-svn: 162853
|
|
|
|
| |
llvm-svn: 162852
|
|
|
|
|
|
| |
The patch suggested by Logan Chien.
llvm-svn: 162840
|
|
|
|
|
|
| |
current available documentation.
llvm-svn: 162065
|
|
|
|
|
|
| |
constraints we don't recognize.
llvm-svn: 162064
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of adding it to each individual subclass in
Targets.cpp, simply check the appropriate target
values.
Where before it was only on x86_64 and ppc64, it's now
also defined on mips64 and nvptx64.
Also add a bunch of negative tests to ensure it is *not*
defined on any other architectures while we're here.
llvm-svn: 161685
|
|
|
|
| |
llvm-svn: 161546
|
|
|
|
|
|
| |
Contributed by Brad Smith <brad@comstyle.com>
llvm-svn: 161481
|
|
|
|
|
|
| |
Contributed by Brad Smith <brad@comstyle.com>
llvm-svn: 161175
|
|
|
|
|
|
|
| |
This fixes PR13502 and adds a test to keep track of which
targets support TLS and which do not.
llvm-svn: 161124
|
|
|
|
|
|
|
|
|
|
| |
due to
AVX). Currently, if no aligned attribute is specified the alignment of a vector is
inferred from its size. Thus, very large vectors will be over-aligned with no
benefit. Target owners should set this target max.
llvm-svn: 160209
|
|
|
|
|
|
|
|
| |
Fixes bug 13322
Patch by Dmitry Mikushin
llvm-svn: 160050
|
|
|
|
|
|
|
| |
For some reason GCC decided to call the feature rdrnd instead of rdrand,
which requires translating it for LLVM.
llvm-svn: 159897
|
|
|
|
| |
llvm-svn: 159829
|
|
|
|
|
|
| |
if -mdsp or -mdspr2 options are provided.
llvm-svn: 159774
|
|
|
|
| |
llvm-svn: 159769
|
|
|
|
| |
llvm-svn: 159753
|
|
|
|
|
|
| |
float ABI.
llvm-svn: 159752
|
|
|
|
| |
llvm-svn: 159747
|
|
|
|
|
|
| |
Patch by Andy Gibbs.
llvm-svn: 159665
|