| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 165402
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
being applied to all accesses to an alloca, not just the ones which read from the GEP. Thanks to Evan for reducing the test. rdar://11861001
llvm-svn: 161654
|
|
|
|
| |
llvm-svn: 160668
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
A patch by Tom Stellard with minor changes.
llvm-svn: 158918
|
|
|
|
|
|
| |
it to be able to replace operations on these vector alloca's with insert/extract element insts
llvm-svn: 158623
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
the vectors are dynamically indexed
llvm-svn: 158529
|
|
|
|
|
|
| |
is out of range to be replaced with a scalar access. Now with additional fix and test for indexing into a vector inside a struct
llvm-svn: 158479
|
|
|
|
|
|
|
|
| |
vectorise buildbot
This reverts commit 12c1f86ffa731e2952c80d2cc577000c96b8962c.
llvm-svn: 158462
|
|
|
|
|
|
| |
is out of range to be replaced with a scalar access. Now with additional fix and test for indexing into a vector inside a struct
llvm-svn: 158454
|
|
|
|
|
|
|
|
| |
range to be replaced with a scalar access"
This reverts commit 51786e0aaec76b973205066bd44f7f427b21969f.
llvm-svn: 158408
|
|
|
|
|
|
| |
be replaced with a scalar access
llvm-svn: 158407
|
|
|
|
|
|
|
| |
copied-in constant, as a subsequent user may rely on over alignment.
Fixes PR12885.
llvm-svn: 157134
|
|
|
|
| |
llvm-svn: 154522
|
|
|
|
| |
llvm-svn: 153322
|
|
|
|
| |
llvm-svn: 153237
|
|
|
|
|
|
| |
Fixes PR12202.
llvm-svn: 152756
|
|
|
|
| |
llvm-svn: 151262
|
|
|
|
| |
llvm-svn: 148929
|
|
|
|
| |
llvm-svn: 147284
|
|
|
|
| |
llvm-svn: 145801
|
|
|
|
|
|
|
|
| |
Suggested in code review by Eli.
That code in InstCombine looks kinda suspicious.
llvm-svn: 145013
|
|
|
|
|
|
| |
Fixes PR11353.
llvm-svn: 144442
|
|
|
|
|
|
|
| |
element types, even though the element extraction code does. It is surprising
that this bug has been here for so long. Fixes <rdar://problem/10318778>.
llvm-svn: 142740
|
|
|
|
|
|
|
|
| |
would have never worked, since the element type of a vector type is never a
vector type. Also fix the conditional to be more direct in checking whether
EltTy is a vector type.
llvm-svn: 141713
|
|
|
|
|
|
|
| |
lowering of NEON code. It provides little-to-no benefit now and only introduces
additional complexity.
llvm-svn: 141646
|
|
|
|
|
|
|
|
| |
to be uniqued, without any benefit.
If someone prefers %tmp42 to %42, run instnamer.
llvm-svn: 140634
|
|
|
|
| |
llvm-svn: 140327
|
|
|
|
|
|
|
|
| |
No tests; these changes aren't really interesting in the sense that the logic is the same for volatile and atomic.
I believe this completes all of the changes necessary for the optimizer to handle loads and stores correctly. I'm going to try and come up with some additional testing, though.
llvm-svn: 139533
|
|
|
|
| |
llvm-svn: 136008
|
|
|
|
| |
llvm-svn: 135904
|
|
|
|
|
|
|
| |
size but different element types, so that it filters out the cases
that CreateShuffleVectorCast doesn't handle. This fixes rdar://9786827.
llvm-svn: 135721
|
|
|
|
| |
llvm-svn: 135478
|
|
|
|
| |
llvm-svn: 135375
|
|
|
|
| |
llvm-svn: 134568
|
|
|
|
|
|
| |
one alloca.
llvm-svn: 134549
|
|
|
|
| |
llvm-svn: 134538
|
|
|
|
| |
llvm-svn: 134235
|
|
|
|
|
|
|
|
| |
alloca that only holds a copy of a global and we're going to replace the users
of the alloca with that global, just nuke the lifetime intrinsics. Part of
PR10121.
llvm-svn: 133905
|
|
|
|
|
|
|
|
|
|
|
|
| |
type's bitwidth matches the (allocated) size of the alloca. This severely
pessimizes vector scalar replacement when the only vector type being used is
something like <3 x float> on x86 or ARM whose allocated size matches a
<4 x float>.
I hope to fix some of the flawed assumptions about allocated size throughout
scalar replacement and reenable this in most cases.
llvm-svn: 133338
|
|
|
|
|
|
| |
alloca. Fixes part of <rdar://problem/9580800>.
llvm-svn: 133336
|
|
|
|
|
|
| |
unless ScalarKind is Vector.
llvm-svn: 133335
|
|
|
|
| |
llvm-svn: 132982
|
|
|
|
| |
llvm-svn: 132952
|
|
|
|
| |
llvm-svn: 132940
|
|
|
|
| |
llvm-svn: 132939
|