| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
This happens when codegenprepare is invoked via opt.
llvm-svn: 159457
|
| |
|
|
|
|
| |
really happening. No intended functionality change.
llvm-svn: 159451
|
| |
|
|
|
|
| |
not ready to handle invokes. instcombine will take care of this.
llvm-svn: 159440
|
| |
|
|
|
|
|
| |
the optimizers producing a multiply expression with more multiplications than
the original (!).
llvm-svn: 159426
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
(a.k.a. MDNodes). The module doesn't belong in Analysis. Move it to the VMCore
instead.
llvm-svn: 159414
|
| |
|
|
| |
llvm-svn: 159385
|
| |
|
|
| |
llvm-svn: 159384
|
| |
|
|
|
|
| |
BB. This is (hopefully temporary) workaround for PR13225
llvm-svn: 159344
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When both a load/store and its address computation are being vectorized, it can
happen that the address-computation vectorization destroys SCEV's ability
to analyize the relative pointer offsets. As a result (like with the aliasing
analysis info), we need to precompute the necessary information prior to
instruction fusing.
This was found during stress testing (running through the test suite with a very
low required chain length); unfortunately, I don't have a small test case.
llvm-svn: 159332
|
| |
|
|
|
|
|
| |
A shuffle mask will always be a constant, but I did not realize that
when I originally wrote the code.
llvm-svn: 159331
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original algorithm only used recursive pair fusion of equal-length
types. This is now extended to allow pairing of any types that share
the same underlying scalar type. Because we would still generally
prefer the 2^n-length types, those are formed first. Then a second
set of iterations form the non-2^n-length types.
Also, a call to SimplifyInstructionsInBlock has been added after each
pairing iteration. This takes care of DCE (and a few other things)
that make the following iterations execute somewhat faster. For the
same reason, some of the simple shuffle-combination cases are now
handled internally.
There is some additional refactoring work to be done, but I've had
many requests for this feature, so additional refactoring will come
soon in future commits (as will additional test cases).
llvm-svn: 159330
|
| |
|
|
|
|
|
|
|
|
|
| |
Instruction::isSameOperationAs.
Maintaining this kind of checking in different places is dangerous, extending
Instruction::isSameOperationAs consolidates this logic into one place. Here
I've added an optional flags parameter and two flags that are important for
vectorization: CompareIgnoringAlignment and CompareUsingScalarTypes.
llvm-svn: 159329
|
| |
|
|
|
|
|
|
|
| |
include/llvm/Analysis/DebugInfo.h to include/llvm/DebugInfo.h.
The reasoning is because the DebugInfo module is simply an interface to the
debug info MDNodes and has nothing to do with analysis.
llvm-svn: 159312
|
| |
|
|
|
|
|
|
|
|
|
| |
Original commit message:
If a constant or a function has linkonce_odr linkage and unnamed_addr, mark it
hidden. Being linkonce_odr guarantees that it is available in every dso that
needs it. Being a constant/function with unnamed_addr guarantees that the
copies don't have to be merged.
llvm-svn: 159272
|
| |
|
|
|
|
|
|
|
|
|
| |
before the expression root. Any existing operators that are changed to use one
of them needs to be moved between it and the expression root, and recursively
for the operators using that one. When I rewrote RewriteExprTree I accidentally
inverted the logic, resulting in the compacting going down from operators to
operands rather than up from operands to the operators using them, oops. Fix
this, resolving PR12963.
llvm-svn: 159265
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
// 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
|
| |
|
|
|
|
| |
perfectly ok to mark realloc as noalias
llvm-svn: 159175
|
| |
|
|
|
|
| |
whole thing should be upgraded to use the MemoryBuiltin interface anyway..
llvm-svn: 159173
|
| |
|
|
|
|
|
| |
the call correctly even in the case where it is an invoke. This
fixes rdar://11714057.
llvm-svn: 159157
|
| |
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
|
| |
hidden. Being linkonce_odr guarantees that it is available in every dso that
needs it. Being a constant/function with unnamed_addr guarantees that the
copies don't have to be merged.
llvm-svn: 159136
|
| |
|
|
|
|
| |
longer represents what the function does. Therefore, the function is removed and its functionality is folded into the only place in the code-base where it was being used.
llvm-svn: 159133
|
| |
|
|
| |
llvm-svn: 159112
|
| |
|
|
|
|
|
|
| |
integer types.
These are used as the result of comparisons, and often handled differently from larger integer types.
llvm-svn: 159111
|
| |
|
|
|
|
|
| |
the safety check to look for the same type we're going to actually cast to.
Fixes PR13180!
llvm-svn: 159110
|
| |
|
|
| |
llvm-svn: 159104
|
| |
|
|
| |
llvm-svn: 159096
|
| |
|
|
| |
llvm-svn: 159088
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows the user/front-end to specify a model that is better
than what LLVM would choose by default. For example, a variable
might be declared as
@x = thread_local(initialexec) global i32 42
if it will not be used in a shared library that is dlopen'ed.
If the specified model isn't supported by the target, or if LLVM can
make a better choice, a different model may be used.
llvm-svn: 159077
|
| |
|
|
|
|
|
|
| |
Local.cpp, Execution.cpp and BitcodeWriter.cpp.
I got about 1% of compile-time improvement on my machines (Ubuntu 11.10 i386 and Ubuntu 12.04 x64).
llvm-svn: 159076
|
| |
|
|
| |
llvm-svn: 159055
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
Original message:
Performance optimizations:
- SwitchInst: case values stored separately from Operands List. It allows to make faster access to individual case value numbers or ranges.
- Optimized IntItem, added APInt value caching.
- Optimized IntegersSubsetGeneric: added optimizations for cases when subset is single number or when subset consists from single numbers only.
llvm-svn: 158997
|
| |
|
|
|
|
| |
sorry for the churn :S enough for today; going to sleep.
llvm-svn: 158953
|
| |
|
|
|
|
| |
user. Update GlobalOpt accordingly.
llvm-svn: 158952
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
most of the code from here).
Remove the alloc_size.ll test until we settle on a metadata format that makes everyone happy..
llvm-svn: 158920
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
| |
A patch by Tom Stellard with minor changes.
llvm-svn: 158918
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'll admit I'm not entirely satisfied with this change, but it seemed
the cleanest option. Other suggestions quite welcome
The issue is that the traits specializations have static methods which
return the typedef'ed PHI_iterator type. In both the IR and MI layers
this is typedef'ed to a custom iterator class defined in an anonymous
namespace giving the types and the functions returning them internal
linkage. However, because the traits specialization is defined in the
'llvm' namespace (where it has to be, specialized template lives there),
and is in turn used in the templated implementation of the SSAUpdater.
This led to the linkage conflict that Clang now warns about.
The simplest solution to me was just to define the PHI_iterator as
a nested class inside the trait specialization. That way it still
doesn't get scoped widely, it can't be accidentally reused somewhere,
etc. This is a little gross just because nested class definitions are
a little gross, but the alternatives seem more ad-hoc.
llvm-svn: 158799
|
| |
|
|
|
|
| |
it to be able to replace operations on these vector alloca's with insert/extract element insts
llvm-svn: 158623
|
| |
|
|
|
|
|
|
|
|
|
|
| |
instructions.
The present implementation handles only TBAA and FP metadata, discarding everything else.
For debug metadata, the current behavior is maintained (the debug metadata associated with
one of the instructions will be kept, discarding that attached to the other).
This should address PR 13040.
llvm-svn: 158606
|
| |
|
|
|
|
|
| |
There are other passes, BBVectorize specifically, that also need some of
this functionality.
llvm-svn: 158605
|
| |
|
|
|
|
| |
SmallSetVector. Patch by Daniel Reynaud. rdar://11671029
llvm-svn: 158594
|
| |
|
|
|
|
|
|
| |
Dynamic GEPs created by SROA needed to insert extra "i32 0"
operands to index through structs and arrays to get to the
vector being indexed.
llvm-svn: 158590
|