Also switch the return type to ArrayRef<unsigned> which works out nicely
for ARM's implementation of this function because of the clever ArrayRef
constructors.
The name change indicates that the returned allocation order may contain
reserved registers as has been the case for a while.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133216 91177308-0d34-0410-b5e6-96231b3b80d8
In Thumb mode we cannot handle GPR virtual registers, even though some
instructions can. When isel is lowering a CopyFromReg, it should limit
itself to subclasses of getRegClassFor(VT).
<rdar://problem/9624323>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133210 91177308-0d34-0410-b5e6-96231b3b80d8
I think PBQP could use RegisterClassInfo, but it didn't fit neatly with
the external interfaces that PBQP uses, so I'll leave that to Lang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133186 91177308-0d34-0410-b5e6-96231b3b80d8
BranchProbabilityInfo (expect setEdgeWeight which is not available here).
Branch Weights are kept in MachineBasicBlocks. To turn off this analysis
set -use-mbpi=false.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133184 91177308-0d34-0410-b5e6-96231b3b80d8
This is intended to support using REG_SEQUENCE SDNode's with type MVT::untyped, and is part of the long road to eliminating some of the hacks we currently use to support register pairs and other strange constraints, particularly on ARM NEON.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133178 91177308-0d34-0410-b5e6-96231b3b80d8
This avoids the manual filtering of reserved registers and removes the
dependency on allocation_order_begin().
Palliative care...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133177 91177308-0d34-0410-b5e6-96231b3b80d8
This virtual function will replace allocation_order_begin/end as the one
to override when implementing custom allocation orders. It is simpler to
have one function return an ArrayRef than having two virtual functions
computing different ends of the same array.
Use getRawAllocationOrder() in place of allocation_order_begin() where
it makes sense, but leave some clients that look like they really want
the filtered allocation orders from RegisterClassInfo.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133170 91177308-0d34-0410-b5e6-96231b3b80d8
accumulator forwarding. Specifically (from SVN log entry):
Distribute (A + B) * C to (A * C) + (B * C) to make use of NEON multiplier
accumulator forwarding:
vadd d3, d0, d1
vmul d3, d3, d2
=>
vmul d3, d0, d2
vmla d3, d1, d2
Make sure it catches cases where operand 1 is add/fadd/sub/fsub, which was
intended in the original revision.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133127 91177308-0d34-0410-b5e6-96231b3b80d8
The limit in this patch is probably too high, but it is enough to stop DSE from going completely insane on a testcase I have (which has a single block with around 50,000 non-aliasing stores in it).
rdar://9471075
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133111 91177308-0d34-0410-b5e6-96231b3b80d8
This simplifies many of the target description files since it is common
for register classes to be related or contain sequences of numbered
registers.
I have verified that this doesn't change the files generated by TableGen
for ARM and X86. It alters the allocation order of MBlaze GPR and Mips
FGR32 registers, but I believe the change is benign.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133105 91177308-0d34-0410-b5e6-96231b3b80d8
optimizations when emitting calls to the function; instead those calls may
use faster relocations which require the function to be immediately resolved
upon loading the dynamic object featuring the call. This is useful when it
is known that the function will be called frequently and pervasively and
therefore there is no merit in delaying binding of the function.
Currently only implemented for x86-64, where it turns into a call through
the global offset table.
Patch by Dan Gohman, who assures me that he's going to add LangRef documentation
for this once it's committed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133080 91177308-0d34-0410-b5e6-96231b3b80d8
Re-apply 133010, with fixes for inline assembler.
Original commit message:
"When an assembler local symbol is used but not defined in a module, a
Darwin assembler wants to issue a diagnostic to that effect."
Added fix to only perform the check when finalizing, as otherwise we're not
done and undefined symbols may simply not have been encountered yet.
Passes "make check" and a self-host check on Darwin.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133071 91177308-0d34-0410-b5e6-96231b3b80d8
Note that this actually changes code generation, and someone who
understands this target better should check the changes.
- R12Q is now allocatable. I think it was omitted from the allocation
order by mistake since it isn't reserved. It as apparently used as a
GOT pointer sometimes, and it should probably be reserved if that is
the case.
- The GR64 registers are allocated in a different order now. The
register allocator will automatically put the CSRs last. There were
other changes to the order that may have been significant.
The test fix is because r0 and r1 swapped places in the allocation order.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133067 91177308-0d34-0410-b5e6-96231b3b80d8
GetDemandBits (which must operate on the vector element type).
Fix the a usage of getZeroExtendInReg which must also be done on scalar types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133052 91177308-0d34-0410-b5e6-96231b3b80d8
At the time I wrote this code (circa 2007), TargetRegisterInfo was using a std::set to perform these queries. Switching to the static hashtables was an obvious improvement, but in reality there's no reason to do anything other than scan.
With this change, total LLC time on a whole-program 403.gcc is reduced by approximately 1.5%, almost all of which comes from a 15% reduction in LiveVariables time. It also reduces the binary size of LLC by 86KB, thanks to eliminating a bunch of very large static tables.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133051 91177308-0d34-0410-b5e6-96231b3b80d8
Unfortunately we can't follow what the rest of the language does (wrapping it
in double-quotes) because that would cause an ambiguity with metadata strings,
so instead we escape any unusual characters with \xx escaping.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133050 91177308-0d34-0410-b5e6-96231b3b80d8
the bits being cleared by the AND are not demanded by the BFI.
The previous BFI dag combine rule was actually incorrect (or used to be
correct until BFI representation changed).
rdar://9609030
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133034 91177308-0d34-0410-b5e6-96231b3b80d8
toString() now takes an optional bool argument that,
depending on the radix, adds the appropriate prefix
to the integer's string representation that makes it into a
meaningful C literal, e.g.:
hexademical: '-f' becomes '-0xf'
octal: '77' becomes '077'
binary: '110' becomes '0b110'
Patch by nobled@dreamwidth.org!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133032 91177308-0d34-0410-b5e6-96231b3b80d8
converted to add x,x if x is a undef. add undef, undef does not guarantee
that the resulting low order bit is zero.
Fixes <rdar://problem/9453156> and <rdar://problem/9487392>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133022 91177308-0d34-0410-b5e6-96231b3b80d8
Roman, since you're writing tests for other PPC-SVR4 vararg-related stuff, would you mind writing a test for this?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133018 91177308-0d34-0410-b5e6-96231b3b80d8
When an assembler local symbol is used but not defined in a module, a
Darwin assembler wants to issue a diagnostic to that effect.
rdar://9559714
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133010 91177308-0d34-0410-b5e6-96231b3b80d8
Dan noted that this would work on the case shown on the commit message. I think
the case that was failing was a bb ending with a redundant conditional jump:
...
jne foo
foo:
...
I was unable to find any such case in the tests or in a debug build of clang,
so I will revert this part of the patch and watch the bots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133004 91177308-0d34-0410-b5e6-96231b3b80d8
types (with power of two types such as 8,16,32 .. 512).
Fix a bug in the integer promotion of bitcast nodes. Enable integer expanding
only if the target of the conversion is an integer (when the type action is
scalarize).
Add handling to the legalization of vector load/store in cases where the saved
vector is integer-promoted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132985 91177308-0d34-0410-b5e6-96231b3b80d8
sharp all or nothing transition when one extra predecessor was added. Now
we still test first ones for merging.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132974 91177308-0d34-0410-b5e6-96231b3b80d8
spartan right now, but I plan to encode more information in this enum to improve
the correctness and reliability of SRoA. At least this first pass makes it
possible to make VectorTy an actual VectorType.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132937 91177308-0d34-0410-b5e6-96231b3b80d8
The logic for reserving R4 for use as a scratch needs to match that for
actually using it. Also, it's not necessary for immediate <=508, so adjust
the value checked.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132934 91177308-0d34-0410-b5e6-96231b3b80d8
might overflow. Re-typing the alloca to a larger type (e.g. double)
hoists a shift into the alloca, potentially exposing overflow in the
expression. rdar://problem/9265821
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132926 91177308-0d34-0410-b5e6-96231b3b80d8
intrinsics. In fact, we'll optimize a bitcast to that when possible. Detect it
when looking for the lifetime intrinsics.
No test case, noticed by inspection.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132906 91177308-0d34-0410-b5e6-96231b3b80d8
In particular, don't spill dirty registers only to satisfy a hint. It is
not worth it.
The attached test case provides an example where the fast allocator
would spill a register when other registers are available.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132900 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of scalarizing, and doing an element-by-element truncat, use vector
truncate.
Add support for scalarization of vectors: i8 -> <1 x i1> (from Duncan's
testcase).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132892 91177308-0d34-0410-b5e6-96231b3b80d8
we try to branch to them.
Before we were creating successor lists with duplicated entries. Fixing that
found a bug in isBlockOnlyReachableByFallthrough that would causes it to
return the wrong answer for
-----------
...
jne foo
jmp bar
foo:
----------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132882 91177308-0d34-0410-b5e6-96231b3b80d8
functionality change.
Later on, we'll use the flag to emit SEH pseudo-ops that describe how the
call frame was built.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132880 91177308-0d34-0410-b5e6-96231b3b80d8
memcpy/memset symbol doesn't get marked up correctly in PIC modes otherwise.
Should fix llvm-x86_64-linux-checks buildbot. Followup to r132864.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132869 91177308-0d34-0410-b5e6-96231b3b80d8
Patch by: Jakub Staszak!
Introduces BranchProbability. Changes unsigned to uint32_t all over and
uint64_t only when overflow is expected.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132867 91177308-0d34-0410-b5e6-96231b3b80d8
default, since it usually has very few elements. This speeds up
alias queries in many cases, because AliasCache.clear() doesn't
have to visit as many buckets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132862 91177308-0d34-0410-b5e6-96231b3b80d8
and definitions when emitting global variables. This was causing global
declarations to be emitted as if they were definitions.
Fixes <rdar://problem/9429892>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132825 91177308-0d34-0410-b5e6-96231b3b80d8
With this I am able to bootstrap clang with early tail duplication enabled
for any small bb and setting tail-dup-size to a relatively large value(8) to
stress this code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132816 91177308-0d34-0410-b5e6-96231b3b80d8
causing an assertion failure downstream. This fixes <rdar://problem/9562908>.
This really seems like it should always be set at CCState creation time, so mistakes like
this can never happen. I'll take a look at doing that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132811 91177308-0d34-0410-b5e6-96231b3b80d8
The potential DAGCombine which enforces this more generally messes up some other very fragile patterns, so I'm leaving that alone, at least for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132809 91177308-0d34-0410-b5e6-96231b3b80d8
VK_PPC_{HA,LO}16 into darwin and gas variants.
Darwin wants {ha,lo}16(symbol) while gnu as wants symbol@{ha,l}.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132802 91177308-0d34-0410-b5e6-96231b3b80d8
pad, separating the exception and selector calls from the new lpad. Teaching
it not to do that, or to properly adjust the CFG afterwards, is out of
scope because it would require the other edges to the landing pad to be split
as well (effectively). Instead, just recover from the most likely cases
during inlining. The best long-term solution is to change the exception
representation and commit to either requiring or not requiring the more
complex edge-splitting logic; this is just a shorter-term hack.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132799 91177308-0d34-0410-b5e6-96231b3b80d8
The register allocators automatically filter out reserved registers and
place the callee saved registers last in the allocation order, so custom
methods are no longer necessary just for that.
Some targets still use custom allocation orders:
ARM/Thumb: The high registers are removed from GPR in thumb mode. The
NEON allocation orders prefer to use non-VFP2 registers first.
X86: The GR8 classes omit AH-DH in x86-64 mode to avoid REX trouble.
SystemZ: Some of the allocation orders are omitting R12 aliases without
explanation. I don't understand this target well enough to fix that. It
looks like all the boilerplate could be removed by reserving the right
registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132781 91177308-0d34-0410-b5e6-96231b3b80d8
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
