assuming that all offsets are legal vector accesses, and thus trying to access
the float member of { <2 x float>, float } as the 3rd element of the first
member.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132766 91177308-0d34-0410-b5e6-96231b3b80d8
former was using the size of the entire alloca, whereas the latter was correctly using
the allocated size of the immediate type being converted (which may differ from the size
of the alloca). This fixes PR10082.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132759 91177308-0d34-0410-b5e6-96231b3b80d8
- cfi directives are not inserted at the right location or in the right order.
- The source MachineLocation for the cfi directive that changes the cfa register
to $fp should be MachineLocation::VirtualFP.
- A PROLOG_LABEL that marks the beginning of cfi_offset directives for
callee-saved register is emitted even when no callee-saved registers are
saved.
- When a callee-saved double precision register is saved, two cfi_offset
directives, one for each of the paired single precision registers, should be
emitted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132703 91177308-0d34-0410-b5e6-96231b3b80d8
I've been sitting on this long enough trying to find a test case. I
think the fix should go in now, but I'll keep working on the test case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132701 91177308-0d34-0410-b5e6-96231b3b80d8
When local live range splitting creates a live range with the same
number of instructions as the old range, mark it as RS_Local. When such
a range is seen again, require that it be split in a way that reduces
the number of instructions. That guarantees we are making progress while
still being able to perform 3 -> 2+3 splits as required by PR10070.
This also means that the PrevSlot map is no longer needed. This was also
used to estimate new spill weights, but that is no longer necessary
after slotIndexes::insertMachineInstrInMaps() got the extra Late
insertion argument.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132697 91177308-0d34-0410-b5e6-96231b3b80d8
Only target-dependent hints require callbacks. The RCI allocation order
has CSR aliases last according to their order of appearance in the
getCalleeSavedRegs list. This can depend on the calling convention.
This way, AllocationOrder::next doesn't have to check for reserved
registers, and CSRs are always allocated last, even with weird calling
conventions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132690 91177308-0d34-0410-b5e6-96231b3b80d8
The order of registers returned by getCalleeSavedRegs is used to lay out
the fixed stack slots for CSRs. Some targets like their CSRs used from
one end, and some targets want them used from the other end.
When computing an allocation order, simply preserve the relative
ordering of CSRs that the target specifies in its allocation order.
Reordering CSRs would break some targets, ARM in particular.
We still place volatiles before the CSRs, providing slightly better
results with different calling conventions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132680 91177308-0d34-0410-b5e6-96231b3b80d8
VK_GOTOFF reloc. This matches as' behavior, but it is not clear why the linker
might need this, so I added a FIXME.
I could test this by duplicating test/MC/ELF/got.s, but it doesn't look
worthwhile.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132655 91177308-0d34-0410-b5e6-96231b3b80d8
(only happens when using the -promote-elements option).
The correct legalization order is to first try to promote element. Next, we try
to widen vectors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132648 91177308-0d34-0410-b5e6-96231b3b80d8
then we don't want to set the destination in the indirect branch to the
destination. This is because the indirect branch needs its destinations to have
had their block addresses taken. This isn't so of the new critical edge that's
split during this process. If it turns out that the destination block has only
one predecessor, and that being a BB with an indirect branch, then it won't be
marked as 'used' and may be removed.
PR10072
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132638 91177308-0d34-0410-b5e6-96231b3b80d8
redundant with partially-aliasing loads.
When computing what portion of a clobbering load value is needed,
it doesn't consider phi-translation which may have occurred
between the clobbing load and the redundant load.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132631 91177308-0d34-0410-b5e6-96231b3b80d8
BranchProbabilityInfo provides an interface for IR passes to query the
likelihood that control follows a CFG edge. This patch provides an
initial implementation of static branch predication that will populate
BranchProbabilityInfo for branches with no external profile
information using very simple heuristics. It currently isn't hooked up
to any external profile data, so static prediction does all the work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132613 91177308-0d34-0410-b5e6-96231b3b80d8
queries in the case of a DAG, where a query reaches a node
visited earlier, but it's not on a cycle. This avoids
MayAlias results in cases where BasicAA is expected to
return MustAlias or PartialAlias in order to protect TBAA.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132609 91177308-0d34-0410-b5e6-96231b3b80d8
Materializing the stack pointer update before a call requires a scratch
register that may not be available.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132601 91177308-0d34-0410-b5e6-96231b3b80d8
of reserved registers.
Use RegisterClassInfo in RABasic as well. This slightly changes som
allocation orders because RegisterClassInfo puts CSR aliases last.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132581 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, these aliases would be ordered alphabetically. (BH, BL)
Print out the computed allocation orders.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132580 91177308-0d34-0410-b5e6-96231b3b80d8
addressing mode problem mentioned in r132559.
Backend part of rdar://9037836 and part of rdar://9119939
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132561 91177308-0d34-0410-b5e6-96231b3b80d8
- Check for MTCTR8 in addition to MTCTR when looking up a hazard.
- When lowering an indirect call use CTR8 when targeting 64bit.
- Introduce BCTR8 that uses CTR8 and use it on 64bit when expanding ISD::BRIND.
The last change fixes PR8487. With those changes, we are able to compile a
running "ls" and "sh" on FreeBSD/PowerPC64.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132552 91177308-0d34-0410-b5e6-96231b3b80d8
which edge to split by pred/succ pair, which means that we can end up splitting
the wrong edge (by case value) in the switch statement entirely. Fixes PR10031!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132535 91177308-0d34-0410-b5e6-96231b3b80d8
Added asserts whenever attempting to use a potentially
uninitialized pass. This helps people trying to develop a new pass and
people trying to understand the bug reports filed by the former people.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132520 91177308-0d34-0410-b5e6-96231b3b80d8
When compiling a program with lots of small functions like
483.xalancbmk, this makes RAFast 11% faster.
Add some comments to clarify the difference between unallocatable and
reserved registers. It's quite subtle.
The fast register allocator depends on EFLAGS' not being allocatable on
x86. That way it can completely avoid tracking liveness, and it won't
mind when there are multiple uses of a single def.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132514 91177308-0d34-0410-b5e6-96231b3b80d8
Some register classes are only used for instruction operand constraints.
They should never be used for virtual registers. Previously, those
register classes were given an empty allocation order, but now you can
say 'let isAllocatable=0' in the register class definition.
TableGen calculates if a register is part of any allocatable register
class, and makes that information available in TargetRegisterDesc::inAllocatableClass.
The goal here is to eliminate use cases for overriding allocation_order_*
methods.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132508 91177308-0d34-0410-b5e6-96231b3b80d8
I was confused whether new uint8_t[] would zero-initialize the returned
array, and it seems that so is gcc-4.0.
This should fix the test failures on darwin 9.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132500 91177308-0d34-0410-b5e6-96231b3b80d8
Instead, use simpler approach and let DBG_VALUE follow its predecessor instruction. After live debug value analysis pass, all DBG_VALUE instruction are placed at the right place. Thanks Jakob for the hint!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132483 91177308-0d34-0410-b5e6-96231b3b80d8
Parsing a register name/number for .cfi directives can't assume that a
register name starts with a '%' token. Be more flexible and check for a
register number instead. Still unlikely to be perfect, but it allows us
to parse both plain identifiers as register names and integers as register
numbers, which is what we're wanting to support at this point.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132466 91177308-0d34-0410-b5e6-96231b3b80d8
register classes.
It provides information for each register class that cannot be
determined statically, like:
- The number of allocatable registers in a class after filtering out the
reserved and invalid registers.
- The preferred allocation order with registers that overlap callee-saved
registers last.
- The last callee-saved register that overlaps a given physical register.
This information usually doesn't change between functions, so it is
reused for compiling multiple functions when possible. The many
possible combinations of reserved and callee saves registers makes it
unfeasible to compute this information statically in TableGen.
Use RegisterClassInfo to count available registers in various heuristics
in SimpleRegisterCoalescing, making the pass run 4% faster.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132450 91177308-0d34-0410-b5e6-96231b3b80d8
In the given testcase, the "Clobber" was pointing to a load, and GVN was incorrectly assuming that meant that the "Clobber" load overlapped the load being analyzed (when they are actually unrelated).
The included testcase tests both this commit and r132434.
Part two of rdar://9429882. (r132434 was mislabeled.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132442 91177308-0d34-0410-b5e6-96231b3b80d8
floating-point comparison, generate a mask of 0s or 1s, and generally
DTRT with NaNs. Only profitable when the user wants a materialized 0
or 1 at runtime. rdar://problem/5993888
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132404 91177308-0d34-0410-b5e6-96231b3b80d8
Add TargetRegisterInfo::hasSubClassEq and use it to check for compatible
register classes instead of trying to list all register classes in
X86's getLoadStoreRegOpcode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132398 91177308-0d34-0410-b5e6-96231b3b80d8
patch we add a flag to enable a new type legalization decision - to promote
integer elements in vectors. Currently, the rest of the codegen does not support
this kind of legalization. This flag will be removed when the transition is
complete.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132394 91177308-0d34-0410-b5e6-96231b3b80d8
For targets with no itinerary (x86) it is a nop by default. For
targets with issue width already expressed in the itinerary (ARM) it
bypasses a scoreboard check but otherwise does not affect the
schedule. It does make the code more consistent and complete and
allows new targets to specify their issue width in an arbitrary way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132385 91177308-0d34-0410-b5e6-96231b3b80d8
turns out that it could cause an infinite loop in some situations. If this code
is triggered and it converts a cleanup into a catchall, but that cleanup was in
already in a cleanup, then the _Unwind_SjLj_Resume could infinite loop. I.e.,
the code doesn't consume the exception object and passes it on to
_Unwind_SjLj_Resume. But _USjLjR expects it to be consumed (since it's landing
at a catchall instead of a cleanup). So it uses the values that are presently
there, which are the values that tell it to jump to the fake landing pad.
<rdar://problem/9508402>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132381 91177308-0d34-0410-b5e6-96231b3b80d8
When assigned ranges are evicted, they are put in the RS_Evicted stage and are
not allowed to evict anything else. That prevents looping automatically.
When evicting ranges just to get a cheaper register, use only spill weights to
find the possible candidates. Avoid breaking hints for this purpose, it is not
worth it.
Start implementing more complex eviction heuristics, guarded by the temporary
-complex-eviction flag. The initial version permits a heavier range to be
evicted if it doesn't have any uses where the evicting range is live. This makes
it a good candidate for live ranfge splitting.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132358 91177308-0d34-0410-b5e6-96231b3b80d8
must be encoded decremented by one. Only add encoding tests for ssat16
because ssat can't be parsed yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132324 91177308-0d34-0410-b5e6-96231b3b80d8
nand), atomic.swap and atomic.cmp.swap, all in i8, i16 and i32 versions.
The intrinsics are implemented by creating pseudo-instructions, which are
then expanded in the method MipsTargetLowering::EmitInstrWithCustomInserter.
Patch by Sasa Stankovic.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132323 91177308-0d34-0410-b5e6-96231b3b80d8
same dwarf number. This will be used for creating a dwarf number to register
mapping.
The only case that needs this so far is the XMM/YMM registers that unfortunately
do have the same numbers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132314 91177308-0d34-0410-b5e6-96231b3b80d8
handler's data area starts with a 4-byte reference to the personality
function, followed by the DWARF LSDA.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132302 91177308-0d34-0410-b5e6-96231b3b80d8
This only affects targets like Mips where branch instructions may kill virtual
registers. Most other targets branch on flag values, so virtual registers are
not involved.
The problem is that MachineBasicBlock::updateTerminator deletes branches and
inserts new ones while LiveVariables keeps a list of pointers to instructions
that kill virtual registers. That list wasn't properly updated in
MBB::SplitCriticalEdge.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132298 91177308-0d34-0410-b5e6-96231b3b80d8
This is important for the correct lowering of unwind instructions
(which doesn't matter at all) and llvm.eh.resume calls (which does).
Take 2, now with more basic competence.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132295 91177308-0d34-0410-b5e6-96231b3b80d8
This is important for the correct lowering of unwind instructions
(which doesn't matter at all) and llvm.eh.resume calls (which does).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132291 91177308-0d34-0410-b5e6-96231b3b80d8
variable. Noticed by inspection.
Simulate memset in EvaluateFunction where the target of the memset and the
value we're setting are both the null value. Fixes PR10047!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132288 91177308-0d34-0410-b5e6-96231b3b80d8
handler.
At this moment, only GCC-style exceptions are supported. Other kinds
of exceptions, including "traditional" SEH and Microsoft Visual C++ exceptions,
need more work--and an compiler exception model that isn't specific to
GCC-style exceptions!
In particular, I imagine that it would be possible to mix "traditional" SEH
with GCC-style EH or Microsoft C++ EH. Currently LLVM has no way (beyond some
target-specific defaults and whole-module compiler switches) of knowing which
scheme to use when.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132283 91177308-0d34-0410-b5e6-96231b3b80d8
