| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
after legalize. Just because a constant is legal (e.g. 0.0 in SSE)
doesn't mean that its negated value is legal (-0.0). We could make
this stronger by checking to see if the negated constant is actually
legal post negation, but it doesn't seem like a big deal.
llvm-svn: 47591
|
|
|
|
| |
llvm-svn: 47427
|
|
|
|
| |
llvm-svn: 47296
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CTTZ and CTPOP. The expansion code differs from
that in LegalizeDAG in that it chooses to take the
CTLZ/CTTZ count from the Hi/Lo part depending on
whether the Hi/Lo value is zero, not on whether
CTLZ/CTTZ of Hi/Lo returned 32 (or whatever the
width of the type is) for it. I made this change
because the optimizers may well know that Hi/Lo
is zero and exploit it. The promotion code for
CTTZ also differs from that in LegalizeDAG: it
uses an "or" to get the right result when the
original value is zero, rather than using a compare
and select. This also means the value doesn't
need to be zero extended.
llvm-svn: 47075
|
|
|
|
|
|
| |
expand the result of this operator!" (node: ctlz).
llvm-svn: 46713
|
|
|
|
|
|
| |
this operator's operand" (node: extract_subvector).
llvm-svn: 46712
|
|
|
|
| |
llvm-svn: 46711
|
|
|
|
|
|
|
|
|
| |
any bugs in the future since to get the crash you also
need hacked in fake libcall support (which creates odd
but legal trees), but since adding it doesn't hurt...
Thanks to Chris for this ultimately reduced version.
llvm-svn: 46706
|
|
|
|
|
|
|
|
|
|
| |
delete a node even if it was not dead in some cases. Instead, just add it to
the worklist. Also, make sure to use the CombineTo methods, as it was doing
things that were unsafe: the top level combine loop could touch dangling memory.
This fixes CodeGen/Generic/2008-01-25-dag-combine-mul.ll
llvm-svn: 46384
|
|
|
|
| |
llvm-svn: 46139
|
|
|
|
| |
llvm-svn: 46124
|
|
|
|
| |
llvm-svn: 46020
|
|
|
|
| |
llvm-svn: 45795
|
|
|
|
|
|
|
| |
providing a misleading facility. It's used once in the MIPS backend
and hardcoded as "\t.globl\t" everywhere else.
llvm-svn: 45676
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ShadowStackCollector, which additionally has reduced overhead with
no sacrifice in portability.
Considering a function @fun with 8 loop-local roots,
ShadowStackCollector introduces the following overhead
(x86):
; shadowstack prologue
movl L_llvm_gc_root_chain$non_lazy_ptr, %eax
movl (%eax), %ecx
movl $___gc_fun, 20(%esp)
movl $0, 24(%esp)
movl $0, 28(%esp)
movl $0, 32(%esp)
movl $0, 36(%esp)
movl $0, 40(%esp)
movl $0, 44(%esp)
movl $0, 48(%esp)
movl $0, 52(%esp)
movl %ecx, 16(%esp)
leal 16(%esp), %ecx
movl %ecx, (%eax)
; shadowstack loop overhead
(none)
; shadowstack epilogue
movl 48(%esp), %edx
movl %edx, (%ecx)
; shadowstack metadata
.align 3
___gc_fun: # __gc_fun
.long 8
.space 4
In comparison to LowerGC:
; lowergc prologue
movl L_llvm_gc_root_chain$non_lazy_ptr, %eax
movl (%eax), %ecx
movl %ecx, 48(%esp)
movl $8, 52(%esp)
movl $0, 60(%esp)
movl $0, 56(%esp)
movl $0, 68(%esp)
movl $0, 64(%esp)
movl $0, 76(%esp)
movl $0, 72(%esp)
movl $0, 84(%esp)
movl $0, 80(%esp)
movl $0, 92(%esp)
movl $0, 88(%esp)
movl $0, 100(%esp)
movl $0, 96(%esp)
movl $0, 108(%esp)
movl $0, 104(%esp)
movl $0, 116(%esp)
movl $0, 112(%esp)
; lowergc loop overhead
leal 44(%esp), %eax
movl %eax, 56(%esp)
leal 40(%esp), %eax
movl %eax, 64(%esp)
leal 36(%esp), %eax
movl %eax, 72(%esp)
leal 32(%esp), %eax
movl %eax, 80(%esp)
leal 28(%esp), %eax
movl %eax, 88(%esp)
leal 24(%esp), %eax
movl %eax, 96(%esp)
leal 20(%esp), %eax
movl %eax, 104(%esp)
leal 16(%esp), %eax
movl %eax, 112(%esp)
; lowergc epilogue
movl 48(%esp), %edx
movl %edx, (%ecx)
; lowergc metadata
(none)
llvm-svn: 45670
|
|
|
|
|
|
|
|
| |
values, which means doing extra legalization work.
It would be easier to get this kind of thing right if
there was some documentation...
llvm-svn: 45472
|
|
|
|
|
|
| |
collector algorithms.
llvm-svn: 45357
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
define void @f() {
...
call i32 @g()
...
}
define void @g() {
...
}
The hazards are:
- @f and @g have GC, but they differ GC. Inlining is invalid. This
may never occur.
- @f has no GC, but @g does. g's GC must be propagated to @f.
The other scenarios are safe:
- @f and @g have the same GC.
- @f and @g have no GC.
- @g has no GC.
This patch adds inliner checks for the former two scenarios.
llvm-svn: 45351
|
|
|
|
|
|
|
|
|
| |
function with GC.
This will catch the error when the inliner inlines a function with
GC into a caller with no GC.
llvm-svn: 45350
|
|
|
|
|
|
| |
LangRef.
llvm-svn: 45349
|
|
|
|
|
|
|
|
| |
how to lower them (with no attempt made to be
efficient, since they should only occur for
unoptimized code).
llvm-svn: 45108
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
methods are new to Function:
bool hasCollector() const;
const std::string &getCollector() const;
void setCollector(const std::string &);
void clearCollector();
The assembly representation is as such:
define void @f() gc "shadow-stack" { ...
The implementation uses an on-the-side table to map Functions to
collector names, such that there is no overhead. A StringPool is
further used to unique collector names, which are extremely
likely to be unique per process.
llvm-svn: 44769
|
|
|
|
| |
llvm-svn: 44738
|
|
|
|
| |
llvm-svn: 44405
|
|
|
|
| |
llvm-svn: 44378
|
|
|
|
|
|
|
|
| |
node A gets back into the DAG again because it was hiding in
one of the node maps: make sure that node replacement happens
in those maps too.
llvm-svn: 44263
|
|
|
|
| |
llvm-svn: 42505
|
|
|
|
| |
llvm-svn: 42263
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM now enforces the following prototypes for the write barriers:
<ty>* @llvm.gcread(<ty2>*, <ty>**)
void @llvm.gcwrite(<ty>*, <ty2>*, <ty>**)
And for @llvm.gcroot, the first stack slot is verified to be an alloca or a
bitcast of an alloca.
Fixes test/CodeGen/Generic/GC/lower_gcroot.ll, which violated these.
llvm-svn: 42051
|
|
|
|
|
|
|
|
| |
needed, because they just "mark" register
liveins and we let frontend solve type issue, not lowering code :)
llvm-svn: 41763
|
|
|
|
|
|
| |
representable to use hex format.
llvm-svn: 41722
|
|
|
|
| |
llvm-svn: 41668
|
|
|
|
|
|
|
| |
latest EH changes, and in any case it is hard to
imagine how the original bug could be reintroduced.
llvm-svn: 41497
|
|
|
|
|
|
| |
offset needs to be adjusted in this test.
llvm-svn: 41490
|
|
|
|
|
|
|
| |
know how to handle them. This fixes
test/CodeGen/Generic/asm-large-immediate.ll
llvm-svn: 41388
|
|
|
|
| |
llvm-svn: 41100
|
|
|
|
| |
llvm-svn: 41097
|
|
|
|
|
|
|
|
| |
LLVM. It cleans up the intrinsic definitions and generally smooths the process for more complicated intrinsic writing. It will be used by the upcoming atomic intrinsics as well as vector and float intrinsics in the future.
This also changes the syntax for llvm.bswap, llvm.part.set, llvm.part.select, and llvm.ct* intrinsics. They are automatically upgraded by both the LLVM ASM reader and the bitcode reader. The test cases have been updated, with special tests added to ensure the automatic upgrading is supported.
llvm-svn: 40807
|
|
|
|
|
|
|
|
|
| |
mnemonics from their operands instead of single spaces. This makes the
assembly output a little more consistent with various other compilers
(f.e. GCC), and slightly easier to read. Also, update the regression
tests accordingly.
llvm-svn: 40648
|
|
|
|
|
|
| |
believe you can use true regular expressions here. It will just look for those keywords. Please test this on sparc and see if they still are xfailed.
llvm-svn: 39975
|
|
|
|
| |
llvm-svn: 39969
|
|
|
|
|
|
|
|
| |
Move tests that have C/C++ sources into the appropriate directory. This
allows them to be selected for testing based on whether llvm-gcc is
present or not.
llvm-svn: 39963
|
|
|
|
|
|
| |
where it's interpreted as a comment, not part of the syntax.
llvm-svn: 39920
|
|
|
|
|
|
|
| |
Change name of -sched option and DEBUG_TYPE to
pre-RA-sched; adjust testcases.
llvm-svn: 39816
|
|
|
|
| |
llvm-svn: 38464
|
|
|
|
|
|
|
| |
of filter ids, and not simply the id index. Testing
this requires at least 128 type infos!
llvm-svn: 37941
|
|
|
|
| |
llvm-svn: 37927
|
|
|
|
| |
llvm-svn: 37801
|
|
|
|
| |
llvm-svn: 37597
|
|
|
|
| |
llvm-svn: 37462
|