| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Thanks to Eli for noticing the discrepancy.
llvm-svn: 153011
|
|
|
|
|
|
| |
Also do some minor reformatting.
llvm-svn: 152707
|
|
|
|
| |
llvm-svn: 152115
|
|
|
|
| |
llvm-svn: 152111
|
|
|
|
|
|
| |
pin it down is undefined behaviour.
llvm-svn: 151710
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The rule governing the flags is this:
no-gc + no-gc = no-gc
no-gc + gc = no-gc
no-gc + gc-only = error
gc + gc = gc
gc + gc-only = gc-only
gc-only + gc-only = gc-only
llvm-svn: 150646
|
|
|
|
| |
llvm-svn: 150301
|
|
|
|
|
|
| |
the compiler in r144100
llvm-svn: 150257
|
|
|
|
|
|
| |
instruction anyway?!
llvm-svn: 149913
|
|
|
|
| |
llvm-svn: 149876
|
|
|
|
| |
llvm-svn: 148692
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: LLVM needs more function attributes than currently available (32 bits).
One such proposed attribute is "address_safety", which shows that a function is being checked for address safety (by AddressSanitizer, SAFECode, etc).
Solution:
- extend the Attributes from 32 bits to 64-bits
- wrap the object into a class so that unsigned is never erroneously used instead
- change "unsigned" to "Attributes" throughout the code, including one place in clang.
- the class has no "operator uint64 ()", but it has "uint64_t Raw() " to support packing/unpacking.
- the class has "safe operator bool()" to support the common idiom: if (Attributes attr = getAttrs()) useAttrs(attr);
- The CTOR from uint64_t is marked explicit, so I had to add a few explicit CTOR calls
- Add the new attribute "address_safety". Doing it in the same commit to check that attributes beyond first 32 bits actually work.
- Some of the functions from the Attribute namespace are worth moving inside the class, but I'd prefer to have it as a separate commit.
Tested:
"make check" on Linux (32-bit and 64-bit) and Mac (10.6)
built/run spec CPU 2006 on Linux with clang -O2.
This change will break clang build in lib/CodeGen/CGCall.cpp.
The following patch will fix it.
llvm-svn: 148553
|
|
|
|
| |
llvm-svn: 148136
|
|
|
|
| |
llvm-svn: 148065
|
|
|
|
|
|
|
| |
The registers are placed into the saved registers list in the reverse order,
which is why the original loop was written to loop backwards.
llvm-svn: 148064
|
|
|
|
| |
llvm-svn: 147274
|
|
|
|
|
|
|
|
| |
"half precision" floating-point with a first-class type.
This patch adds basic IR support (but not codegen support).
llvm-svn: 146786
|
|
|
|
| |
llvm-svn: 146561
|
|
|
|
| |
llvm-svn: 146461
|
|
|
|
|
|
|
|
|
| |
the behavior with the newly added flag for undefined results on a zero
input.
I'm terrible at documentation, so comments and suggestions welcome here.
llvm-svn: 146361
|
|
|
|
| |
llvm-svn: 146288
|
|
|
|
| |
llvm-svn: 146234
|
|
|
|
|
|
|
|
|
|
| |
recent discussions. Poison can't make every value that depends on
it act in maximally undefined ways, because the optimizer may still
hoist code following the usual rules for undef. Make Poison invoke
its full undefined behavior only when it reaches an instruction with
externally visible side effects.
llvm-svn: 145913
|
|
|
|
| |
llvm-svn: 145908
|
|
|
|
|
|
|
| |
purpose, and to avoid ambiguity with other uses of the word "trap"
in LangRef.
llvm-svn: 145907
|
|
|
|
| |
llvm-svn: 145854
|
|
|
|
| |
llvm-svn: 145801
|
|
|
|
| |
llvm-svn: 145793
|
|
|
|
| |
llvm-svn: 145792
|
|
|
|
| |
llvm-svn: 145522
|
|
|
|
| |
llvm-svn: 145521
|
|
|
|
|
|
| |
only produced by LLVM 2.9 and earlier. LLVM 3.0 and later prefers "load volatile".
llvm-svn: 145172
|
|
|
|
| |
llvm-svn: 144204
|
|
|
|
| |
llvm-svn: 144053
|
|
|
|
| |
llvm-svn: 143737
|
|
|
|
| |
llvm-svn: 143349
|
|
|
|
| |
llvm-svn: 143328
|
|
|
|
| |
llvm-svn: 143135
|
|
|
|
|
|
| |
comments at top of TypeBasedAliasAnalysis.cpp).
llvm-svn: 143134
|
|
|
|
| |
llvm-svn: 142994
|
|
|
|
| |
llvm-svn: 141906
|
|
|
|
| |
llvm-svn: 141734
|
|
|
|
| |
llvm-svn: 141733
|
|
|
|
|
|
| |
stack alignment.
llvm-svn: 141687
|
|
|
|
|
|
|
| |
keyword in LLVM for externally visible linkage.
PR10636
llvm-svn: 141649
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
promoting allocas to preferred alignments that exceed the natural
alignment. This avoids some potentially expensive dynamic stack realignments.
The natural stack alignment is set in target data strings via the "S<size>"
option. Size is in bits and must be a multiple of 8. The natural stack alignment
defaults to "unspecified" (represented by a zero value), and the "unspecified"
value does not prevent any alignment promotions. Target maintainers that care
about avoiding promotions should explicitly add the "S<size>" option to their
target data strings.
llvm-svn: 141599
|
|
|
|
| |
llvm-svn: 141057
|
|
|
|
| |
llvm-svn: 141001
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
init.trampoline and adjust.trampoline intrinsics, into two intrinsics
like in GCC. While having one combined intrinsic is tempting, it is
not natural because typically the trampoline initialization needs to
be done in one function, and the result of adjust trampoline is needed
in a different (nested) function. To get around this llvm-gcc hacks the
nested function lowering code to insert an additional parent variable
holding the adjust.trampoline result that can be accessed from the child
function. Dragonegg doesn't have the luxury of tweaking GCC code, so it
stored the result of adjust.trampoline in the memory GCC set aside for
the trampoline itself (this is always available in the child function),
and set up some new memory (using an alloca) to hold the trampoline.
Unfortunately this breaks Go which allocates trampoline memory on the
heap and wants to use it even after the parent has exited (!). Rather
than doing even more hacks to get Go working, it seemed best to just use
two intrinsics like in GCC. Patch mostly by Sanjoy Das.
llvm-svn: 139140
|
|
|
|
| |
llvm-svn: 138472
|