| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 165465
|
|
|
|
| |
llvm-svn: 165402
|
|
|
|
| |
llvm-svn: 164814
|
|
|
|
|
|
| |
See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164767
llvm-svn: 164768
|
|
|
|
| |
llvm-svn: 164767
|
|
|
|
| |
llvm-svn: 164763
|
|
|
|
| |
llvm-svn: 164629
|
|
|
|
|
|
| |
This avoids a crash in visitAllocaInst when target data isn't available.
llvm-svn: 164539
|
|
|
|
|
|
|
|
| |
a value that is zext'd.
Fixes PR13250.
llvm-svn: 164377
|
|
|
|
| |
llvm-svn: 164117
|
|
|
|
| |
llvm-svn: 163974
|
|
|
|
|
|
| |
loads and stores.
llvm-svn: 163844
|
|
|
|
| |
llvm-svn: 163817
|
|
|
|
| |
llvm-svn: 162911
|
|
|
|
|
|
|
|
| |
because C always rounds towards zero.
Thanks Dirk and Ben.
llvm-svn: 162899
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This disables malloc-specific optimization when -fno-builtin (or -ffreestanding)
is specified. This has been a problem for a long time but became more severe
with the recent memory builtin improvements.
Since the memory builtin functions are used everywhere, this required passing
TLI in many places. This means that functions that now have an optional TLI
argument, like RecursivelyDeleteTriviallyDeadFunctions, won't remove dead
mallocs anymore if the TLI argument is missing. I've updated most passes to do
the right thing.
Fixes PR13694 and probably others.
llvm-svn: 162841
|
|
|
|
|
|
|
|
|
| |
the bit width.
No test case, undefined shifts get folded early, but can occur when other
transforms generate a constant. Thanks to Duncan for bringing this up.
llvm-svn: 162755
|
|
|
|
|
|
| |
and non-const shifts.
llvm-svn: 162751
|
|
|
|
|
|
| |
Thanks Benjamin for noticing this.
llvm-svn: 162749
|
|
|
|
|
|
|
|
|
|
| |
For example:
%1 = lshr i32 %x, 2
%2 = udiv i32 %1, 100
rdar://12182093
llvm-svn: 162743
|
|
|
|
|
|
|
|
|
|
| |
This optimization is really just replacing allocas wholesale with
globals, there is no scalarization.
The underlying motivation for this patch is to simplify the SROA pass
and focus it on splitting and promoting allocas.
llvm-svn: 162271
|
|
|
|
| |
llvm-svn: 162180
|
|
|
|
|
|
| |
single IR instruction.
llvm-svn: 162175
|
|
|
|
| |
llvm-svn: 162174
|
|
|
|
|
|
|
|
|
|
|
|
| |
- memcpy size is wrongly truncated into 32-bit and treat 8GB memcpy is
0-sized memcpy
- as 0-sized memcpy/memset is already removed before SimplifyMemTransfer
and SimplifyMemSet in visitCallInst, replace 0 checking with
assertions.
- replace getZExtValue() with getLimitedValue() according to
Eli Friedman
llvm-svn: 161923
|
|
|
|
|
|
|
|
|
| |
An unsigned value converted to floating-point will always be greater than
a negative constant. Unfortunately InstCombine reversed the check so that
unsigned values were being optimized to always be greater than all positive
floating-point constants. <rdar://problem/12029145>
llvm-svn: 161452
|
|
|
|
|
|
|
|
| |
self-referencing select inst.
This can happen as long as the instruction is not reachable. Instcombine does generate these unreachable malformed selects when doing RAUW
llvm-svn: 160874
|
|
|
|
|
|
| |
vector
llvm-svn: 160835
|
|
|
|
|
|
| |
their operand
llvm-svn: 160823
|
|
|
|
|
|
|
|
|
| |
creating a call to a library function.
Update all clients to pass the TLI information around.
Previous draft reviewed by Eli.
llvm-svn: 160733
|
|
|
|
| |
llvm-svn: 160477
|
|
|
|
|
|
| |
instcombine transformation.
llvm-svn: 160387
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
%shr = lshr i64 %key, 3
%0 = load i64* %val, align 8
%sub = add i64 %0, -1
%and = and i64 %sub, %shr
ret i64 %and
to:
%shr = lshr i64 %key, 3
%0 = load i64* %val, align 8
%sub = add i64 %0, 2305843009213693951
%and = and i64 %sub, %shr
ret i64 %and
The demanded bit optimization is actually a pessimization because add -1 would
be codegen'ed as a sub 1. Teach the demanded constant shrinking optimization
to check for negated constant to make sure it is actually reducing the width
of the constant.
rdar://11793464
llvm-svn: 160101
|
|
|
|
|
|
|
|
|
| |
mallocs/callocs/...
This patch removes ~70 lines in InstCombineLoadStoreAlloca.cpp and makes both functions a bit more aggressive than before :)
In theory, we can be more aggressive when removing an alloca than a malloc, because an alloca pointer should never escape, but we are not taking advantage of this anyway
llvm-svn: 159952
|
|
|
|
|
|
|
|
|
|
|
|
| |
memcpy/memmove/memset, and objectsize users.
This means we can do cheap DSE for heap memory.
Nothing is done if the pointer excapes or has a load.
The churn in the tests is mostly due to objectsize, since we want to make sure we
don't delete the malloc call before evaluating the objectsize (otherwise it becomes -1/0)
llvm-svn: 159876
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was always part of the VMCore library out of necessity -- it deals
entirely in the IR. The .cpp file in fact was already part of the VMCore
library. This is just a mechanical move.
I've tried to go through and re-apply the coding standard's preferred
header sort, but at 40-ish files, I may have gotten some wrong. Please
let me know if so.
I'll be committing the corresponding updates to Clang and Polly, and
Duncan has DragonEgg.
Thanks to Bill and Eric for giving the green light for this bit of cleanup.
llvm-svn: 159421
|
|
|
|
| |
llvm-svn: 159384
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
// C - zext(bool) -> bool ? C - 1 : C
if (ZExtInst *ZI = dyn_cast<ZExtInst>(Op1))
if (ZI->getSrcTy()->isIntegerTy(1))
return SelectInst::Create(ZI->getOperand(0), SubOne(C), C);
This ends up forming sext i1 instructions that codegen to terrible code. e.g.
int blah(_Bool x, _Bool y) {
return (x - y) + 1;
}
=>
movzbl %dil, %eax
movzbl %sil, %ecx
shll $31, %ecx
sarl $31, %ecx
leal 1(%rax,%rcx), %eax
ret
Without the rule, llvm now generates:
movzbl %sil, %ecx
movzbl %dil, %eax
incl %eax
subl %ecx, %eax
ret
It also helps with ARM (and pretty much any target that doesn't have a sext i1 :-).
The transformation was done as part of Eli's r75531. He has given the ok to
remove it.
rdar://11748024
llvm-svn: 159230
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
merge all zero-sized alloca's into one, fixing c43204g from the Ada ACATS
conformance testsuite. What happened there was that a variable sized object
was being allocated on the stack, "alloca i8, i32 %size". It was then being
passed to another function, which tested that the address was not null (raising
an exception if it was) then manipulated %size bytes in it (load and/or store).
The optimizers cleverly managed to deduce that %size was zero (congratulations
to them, as it isn't at all obvious), which made the alloca zero size, causing
the optimizers to replace it with null, which then caused the check mentioned
above to fail, and the exception to be raised, wrongly. Note that no loads
and stores were actually being done to the alloca (the loop that does them is
executed %size times, i.e. is not executed), only the not-null address check.
llvm-svn: 159202
|
|
|
|
|
|
|
|
| |
- simplifycfg: invoke undef/null -> unreachable
- instcombine: invoke new -> invoke expect(0, 0) (an arbitrary NOOP intrinsic; only done if the allocated memory is unused, of course)
- verifier: allow invoke of intrinsics (to make the previous step work)
llvm-svn: 159146
|
|
|
|
| |
llvm-svn: 159112
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes PR5997.
These transforms were disabled because codegen couldn't deal with other
uses of trunc(x). This is now handled by the peephole pass.
This causes no regressions on x86-64.
llvm-svn: 159003
|
|
|
|
|
|
|
|
| |
functionality to SimplifyCFG (since we cannot make changes to the CFG here).
Fixes the crashes with the attached test case
llvm-svn: 158951
|
|
|
|
|
|
| |
rdar://11721329
llvm-svn: 158946
|
|
|
|
|
|
|
|
| |
Update comments accordingly.
Make instcombine remove useless invokes to C++'s 'new' allocation function (test attached).
llvm-svn: 158937
|
|
|
|
|
|
|
|
|
|
|
|
| |
- provide more extensive set of functions to detect library allocation functions (e.g., malloc, calloc, strdup, etc)
- provide an API to compute the size and offset of an object pointed by
Move a few clients (GVN, AA, instcombine, ...) to the new API.
This implementation is a lot more aggressive than each of the custom implementations being replaced.
Patch reviewed by Nick Lewycky and Chandler Carruth, thanks.
llvm-svn: 158919
|
|
|
|
|
|
|
|
|
|
| |
the GEP offset is known to be constant.
With this change, we avoid relying on the IR Builder to constant fold the operations.
No functionality change intended.
llvm-svn: 158829
|
|
|
|
|
|
| |
uno && ueq was converted to ueq, it should be converted to uno.
llvm-svn: 158441
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 158301
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the compare.
This saves a cast, and zext is more expensive on platforms with subreg support
than trunc is. This occurs in the BSD implementation of memchr(3), see PR12750.
On the synthetic benchmark from that bug stupid_memchr and bsd_memchr have the
same performance now when not inlining either function.
stupid_memchr: 323.0us
bsd_memchr: 321.0us
memchr: 479.0us
where memchr is the llvm-gcc compiled bsd_memchr from osx lion's libc. When
inlining is enabled bsd_memchr still regresses down to llvm-gcc memchr time,
I haven't fully understood the issue yet, something is grossly mangling the
loop after inlining.
llvm-svn: 158297
|