s/validName/isValidName/g
s/with an Instruction/to an Instruction/g
s/RegisterMDKind/registerMDKind/g
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84689 91177308-0d34-0410-b5e6-96231b3b80d8
container of the blocks and do efficient lookups. This makes
isLoopSimplifyForm much faster on large loops, fixing a significant
compile-time issue in builds with assertions enabled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84673 91177308-0d34-0410-b5e6-96231b3b80d8
the estimated code size and the number of blocks when deciding whether to
do a non-trivial unswitch. This protects it from some very undesirable
worst-case behavior on large numbers of loop-unswitchable conditions, such
as in the testcase in PR5259.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84661 91177308-0d34-0410-b5e6-96231b3b80d8
JITEmitter.
I'm gradually making Functions auto-remove themselves from the JIT when they're
destroyed. In this case, the Function needs to be removed from the JITEmitter,
but the map recording which Functions need to be removed lived behind the
JITMemoryManager interface, which made things difficult.
This patch replaces the deallocateMemForFunction(Function*) method with a pair
of methods deallocateFunctionBody(void *) and deallocateExceptionTable(void *)
corresponding to the two startFoo/endFoo pairs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84651 91177308-0d34-0410-b5e6-96231b3b80d8
encounters an OEQ or UNE comparison, and update its callers to check
for this return status and recover. This fixes a problem resulting from
the LowerOperation hooks being called from LegalizeVectorOps, because
LegalizeVectorOps only lowers vectors, so OEQ and UNE comparisons may
still be at large. This fixes PR5092.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84640 91177308-0d34-0410-b5e6-96231b3b80d8
When an incoming value for a PHI is updated, we must also updated all other
incoming values for the same BB to match, otherwise we create invalid PHIs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84638 91177308-0d34-0410-b5e6-96231b3b80d8
when the invoke had multiple return values: it set the lattice value only on the
extractvalue.
This caused the invoke's lattice value to remain the default (undefined), and
later propagated to extractvalue's operand, which incorrectly introduces
undefined behavior.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84637 91177308-0d34-0410-b5e6-96231b3b80d8
tracked. Instead of trying to manually keep track of these locations
while doing complex modifications, just recompute them when they're needed.
This fixes a bug in which the TopMBB and BotMBB were not correctly updated,
leading to invalid transformations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84598 91177308-0d34-0410-b5e6-96231b3b80d8
reasonable code like Codegen/ARM/2009-02-27-SpillerBug.ll, producing
identical output except for superior formatting of constant pool entries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84582 91177308-0d34-0410-b5e6-96231b3b80d8
Leave Inst{11-8}, which represents the starting byte index of the extracted
result in the concatenation of the operands and is left unspecified.
Patch by Johnny Chen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84572 91177308-0d34-0410-b5e6-96231b3b80d8
appropriate restore location for the spill as well as perform the actual
save and restore.
The Thumb1 target uses this to make sure R12 is not clobbered while a spilled
scavenger register is live there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84554 91177308-0d34-0410-b5e6-96231b3b80d8
lowering stuff. We can now compile hello world to:
_main:
stm ,
mov r7, sp
sub sp, sp, #4
mov r0, #0
str r0,
ldr r0,
bl _printf
ldr r0,
mov sp, r7
ldm ,
Almost looks like arm code :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84542 91177308-0d34-0410-b5e6-96231b3b80d8
through mcinst lowering -> mcinstprinter, when llc is passed
the -enable-arm-mcinst-printer flag. Currently this
is very "aborty".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84530 91177308-0d34-0410-b5e6-96231b3b80d8
All of these "subreg32" modifier instructions are handled
explicitly by the MCInst lowering phase. If they got to
the asmprinter, they would explode. They should eventually
be replace with correct use of subregs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84526 91177308-0d34-0410-b5e6-96231b3b80d8
The JITResolver maps Functions to their canonical stubs and all callsites for
lazily-compiled functions to their target Functions. To make Function
destruction work, I'm going to need to remove all callsites on destruction, so
this patch also adds the reverse mapping for that.
There was an incorrect assumption in here that the only stub for a function
would be the one caused by needing to lazily compile it, while x86-64 far calls
and dlsym-stubs could also cause such stubs, but I didn't look for a test case
that the assumption broke.
This also adds DenseMapInfo<AssertingVH> so I can use DenseMaps instead of
std::maps.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84522 91177308-0d34-0410-b5e6-96231b3b80d8
where a loop's header is being split and it has predecessors which are not
contained by the most-nested loop which contains the loop.
This fixes PR5235.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84505 91177308-0d34-0410-b5e6-96231b3b80d8
LLC was scheduling compares before the adds causing wrong branches to be taken
in programs, resulting in misoptimized code wherever atomic adds where used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84485 91177308-0d34-0410-b5e6-96231b3b80d8
stack slots and giving them different PseudoSourceValue's did not fix the
problem of post-alloc scheduling miscompiling llvm itself.
- Apply Dan's conservative workaround by assuming any non fixed stack slots can
alias other memory locations. This means a load from spill slot #1 cannot
move above a store of spill slot #2.
- Enable post-alloc scheduling for x86 at optimization leverl Default and above.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84424 91177308-0d34-0410-b5e6-96231b3b80d8
allowing it to simplify the crazy constantexprs in the testcases
down to something sensible. This allows -std-compile-opts to
completely "devirtualize" the pointers to member functions in
the testcase from PR5176.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84368 91177308-0d34-0410-b5e6-96231b3b80d8
to be more general and understand more varieties of loops.
Teach CodePlacementOpt to reorganize the basic blocks of a loop so that
they are contiguous. This also includes a fair amount of logic for preserving
fall-through edges while doing so. This fixes a BranchFolding-ism where blocks
which can't be made to use a fall-through edge and don't conveniently fit
anywhere nearby get tossed out to the end of the function.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84295 91177308-0d34-0410-b5e6-96231b3b80d8
Update testcases that rely on malloc insts being present.
Also prematurely remove MallocInst handling from IndMemRemoval and RaiseAllocations to help pass tests in this incremental step.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84292 91177308-0d34-0410-b5e6-96231b3b80d8
I can see with the original code was that I forgot that this runs after
type legalization and hence the result type will always be i32. (Custom
legalization of EXTRACT_VECTOR_ELT is only enabled for vector types with
8- and 16-bit elements.)
Regarding the FIXME comment: any information about sign and zero-extension
should be captured by separate extension operations. The DAG combiner should
handle those to produce either VGETLANEu or VGETLANEs, and that seems to be
working now. If there are cases that we're missing, let me know.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84218 91177308-0d34-0410-b5e6-96231b3b80d8
1. Emit external function type information for all COFF targets since it's
a feature of object format
2. Emit linker directives only for cygming (since this is ld-specific stuff)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84214 91177308-0d34-0410-b5e6-96231b3b80d8
In the case where there are no good places to put constants and we fall back
upon inserting unconditional branches to make new blocks, allow all constant
pool references in range of those blocks to put constants there, even if that
means resetting the "high water marks" for those references. This will still
terminate because you can't keep splitting blocks forever, and in the bad
cases where we have to split blocks, it is important to avoid splitting more
than necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84202 91177308-0d34-0410-b5e6-96231b3b80d8
as expressions, code for parsing a few arm specific directives (still needs
the MCStreamer calls for these). Some clean up of the operand parsing code
and adding some comments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84201 91177308-0d34-0410-b5e6-96231b3b80d8
identifying the malloc as a non-array malloc. This broke GlobalOpt's optimization of stores of mallocs
to global variables.
The fix is to classify malloc's into 3 categories:
1. non-array mallocs
2. array mallocs whose array size can be determined
3. mallocs that cannot be determined to be of type 1 or 2 and cannot be optimized
getMallocArraySize() returns NULL for category 3, and all users of this function must avoid their
malloc optimization if this function returns NULL.
Eventually, currently unexpected codegen for computing the malloc's size argument will be supported in
isArrayMalloc() and getMallocArraySize(), extending malloc optimizations to those examples.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84199 91177308-0d34-0410-b5e6-96231b3b80d8
When ARMConstantIslandPass cannot find any good locations (i.e., "water") to
place constants, it falls back to inserting unconditional branches to make a
place to put them. My recent change exposed a problem in this area. We may
sometimes append to the same block more than one unconditional branch. The
symptoms of this are that the generated assembly has a branch to an undefined
label and running llc with -debug will cause a seg fault.
This happens more easily since my change to prevent CPEs from moving from
lower to higher addresses as the algorithm iterates, but it could have
happened before. The end of the block may be in range for various constant
pool references, but the insertion point for new CPEs is not right at the end
of the block -- it is at the end of the CPEs that have already been placed
at the end of the block. The insertion point could be out of range. When
that happens, the fallback code will always append another unconditional
branch if the end of the block is in range.
The fix is to only append an unconditional branch if the block does not
already end with one. I also removed a check to see if the constant pool load
instruction is at the end of the block, since that is redundant with
checking if the end of the block is in-range.
There is more to be done here, but I think this fixes the immediate problem.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84172 91177308-0d34-0410-b5e6-96231b3b80d8
don't bother every time going around the main worklist. This speeds up a
release-asserts opt -std-compile-opts on 403.gcc by about 4% (1.5s). It
seems to speed up the most expensive instances of instcombine by ~10%.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84171 91177308-0d34-0410-b5e6-96231b3b80d8
instruction (which disqualifies stores, unreachable, etc) and at least the
first operand is a constant. This filters out a lot of obvious cases that
can't be folded. Also, switch the IRBuilder to a TargetFolder, which tries
harder.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84170 91177308-0d34-0410-b5e6-96231b3b80d8
header is just the entry block to the loop, and it needn't be at
the top of the loop in the code layout.
Remove the code that suppressed loop alignment for outer loops,
so that outer loops are aligned.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84158 91177308-0d34-0410-b5e6-96231b3b80d8
so get rid of eh.selector.i64 and rename eh.selector.i32 to eh.selector.
Likewise for eh.typeid.for. This aligns us with gcc, which always uses a
32 bit value for the selector on all platforms. My understanding is that
the register allocator used to assert if the selector intrinsic size didn't
match the pointer size, and this was the reason for introducing the two
variants. However my testing shows that this is no longer the case (I
fixed some bugs in selector lowering yesterday, and some more today in the
fastisel path; these might have caused the original problems).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84106 91177308-0d34-0410-b5e6-96231b3b80d8
cannot alias the GEP. GEP pointer alias rule states this clearly:
A pointer value formed from a getelementptr instruction is associated with the
addresses associated with the first operand of the getelementptr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84079 91177308-0d34-0410-b5e6-96231b3b80d8
(for uses marked kill and defs marked dead) a few instructions in
addition to forwards. Also, increase the maximum number of instructions
to scan, as it appears to help in a fair number of cases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84061 91177308-0d34-0410-b5e6-96231b3b80d8
to remat non-load instructions as loads, and the remat code now uses
the UnmodeledSideEffects flags, MachineMemOperands, and similar things
to decide which instructions are valid for rematerialization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@84060 91177308-0d34-0410-b5e6-96231b3b80d8
