loads from allocas that cover the entire aggregate. This handles
some memcpy/byval cases that are produced by llvm-gcc. This triggers
a few times in kc++ (with std::pair<std::_Rb_tree_const_iterator
<kc::impl_abstract_phylum*>,bool>) and once in 176.gcc (with %struct..0anon).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61915 91177308-0d34-0410-b5e6-96231b3b80d8
This is a shameless copy of similar APIs from MachineModuleInfo. The copy from MMI will be deleted in near future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61908 91177308-0d34-0410-b5e6-96231b3b80d8
passed in to this function changed to support multiple return values,
leading to some incorrect argument numbers in the failure messages.
With this change, the ArgNo values used for return values and parameters are
disjoint, and the new IntrinsicParam function translates those ArgNo values
to strings that can be used in the messages. This also fixes a few places
where PerformTypeCheck did not return false following calls to CheckFailed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61903 91177308-0d34-0410-b5e6-96231b3b80d8
was it not very helpful, it was also wrong! The problem
is shown in the testcase: the alloca might be passed to
a nocapture callee which dereferences it and returns the
original pointer. But because it was a nocapture call we
think we don't need to track its uses, but we do.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61876 91177308-0d34-0410-b5e6-96231b3b80d8
integer to a (transitive) bitcast the alloca and if that integer
has the full size of the alloca, then it clobbers the whole thing.
Handle this by extracting pieces out of the stored integer and
filing them away in the SROA'd elements.
This triggers fairly frequently because the CFE uses integers to
pass small structs by value and the inliner exposes these. For
example, in kimwitu++, I see a bunch of these with i64 stores to
"%struct.std::pair<std::_Rb_tree_const_iterator<kc::impl_abstract_phylum*>,bool>"
In 176.gcc I see a few i32 stores to "%struct..0anon".
In the testcase, this is a difference between compiling test1 to:
_test1:
subl $12, %esp
movl 20(%esp), %eax
movl %eax, 4(%esp)
movl 16(%esp), %eax
movl %eax, (%esp)
movl (%esp), %eax
addl 4(%esp), %eax
addl $12, %esp
ret
vs:
_test1:
movl 8(%esp), %eax
addl 4(%esp), %eax
ret
The second half of this will be to handle loads of the same form.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61853 91177308-0d34-0410-b5e6-96231b3b80d8
v1024 = EDI // not killed
=
= EDI
One possible solution is for the coalescer to examine the sub-register live intervals in the same manner as the physical register. Another possibility is to examine defs and uses (when needed) of sub-registers. Both solutions are too expensive. For now, look for "short virtual intervals" and scan instructions to look for conflict instead.
This is a small win on x86-64. e.g. It shaves 403.gcc by ~80 instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61847 91177308-0d34-0410-b5e6-96231b3b80d8
into their left operand, rather than their right. Do this
by commuting the operands and inverting the condition.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61842 91177308-0d34-0410-b5e6-96231b3b80d8
to handle LLVMMatchType intrinsic parameters, and by adding new subclasses
of LLVMMatchType to match vector types with integral elements that are
either twice as wide or half as wide as the elements of the matched type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61834 91177308-0d34-0410-b5e6-96231b3b80d8
converted to LEA64_32r in x86's convertToThreeAddress. This
replaces code like this:
movl %esi, %edi
inc %edi
with this:
lea 1(%rsi), %edi
which appears to be beneficial.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61830 91177308-0d34-0410-b5e6-96231b3b80d8
- Add preliminary support for v2i32; load/store generates the right code but
there's a lot work to be done to make this vector type operational.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61829 91177308-0d34-0410-b5e6-96231b3b80d8
aggregate types. Don't increment the current index after reaching
the end of a struct, as it will already be pointing at
one-past-the end. This fixes PR3288.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61828 91177308-0d34-0410-b5e6-96231b3b80d8
two address instructions. We need to keep track of things we've processed AS USES
independetly of whether we've processed them as defs.
This fixes all known miscompilations when reconstruction is turned on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61802 91177308-0d34-0410-b5e6-96231b3b80d8
- Fix bugs 3194, 3195: i128 load/stores produce correct code (although, we
need to ensure that i128 is 16-byte aligned in real life), and 128 zero-
extends are supported.
- New td file: SPU128InstrInfo.td: this is where all new i128 support should
be put in the future.
- Continue to hammer on i64 operations and test cases; ensure that the only
remaining problem will be i64 mul.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61784 91177308-0d34-0410-b5e6-96231b3b80d8
AddPseudoTwoAddrDeps. This lets the scheduling infrastructure
avoid recalculating node heights. In very large testcases this
was a major bottleneck. Thanks to Roman Levenstein for finding
this!
As a side effect, fold-pcmpeqd-0.ll is now scheduled better
and it no longer requires spilling on x86-32.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61778 91177308-0d34-0410-b5e6-96231b3b80d8
as template arguments instead of as instance variables, exposing more
optimization opportunities to the compiler earlier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61776 91177308-0d34-0410-b5e6-96231b3b80d8
In fact this also deletes those with linkonce linkage,
however this is currently dead because for the moment
aliases aren't allowed to have this linkage type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61742 91177308-0d34-0410-b5e6-96231b3b80d8
own OpActionsCapacity magic number; it can just use ISD::BUILTIN_OP_END,
as long as it takes care to round up when needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61733 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-as: crash11.ll:2:27: function may not return return opaque type
"xw" = tail call opaque @608(label %31)
^
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61722 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-as: crash10.ll:3:35: floating point constant does not have type 'ppc_fp128'
"dumy" = fcmp ult ppc_fp128 "j",9209.4
^
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61721 91177308-0d34-0410-b5e6-96231b3b80d8
This means that we have to include an additional header.
This patch should be functionally equivalent. I cannot outrule any performance
degradation, though I do not expect any.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61694 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-as: crash07.ll:2:32: va_arg requires operand with first class type
%y = va_arg [52 x <{}>] %43, double (...) sspreq
^
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61683 91177308-0d34-0410-b5e6-96231b3b80d8
just be removed. However, this fixes PR3281:crash04.ll, diagnosing it with:
lvm-as: crash04.ll:2:13: vfcmp requires vector floating point operands
vfcmp uno double* undef, undef
^
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61680 91177308-0d34-0410-b5e6-96231b3b80d8
SingleSource/UnitTests/2007-04-25-weak.c in JIT mode. The test
now passes on systems which are able to produce a correct
reference output to compare with.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61674 91177308-0d34-0410-b5e6-96231b3b80d8
- Fix (brcond (setq ...)) bug, where BRNZ should have been used vice BRZ.
- Kill unused/unnecessary nodes in SPUNodes.td
- Beef out the i64operations.c test harness to use a lot of unaligned
loads, test loops and LLVM loop/basic block optimizations; run the
test harness successfully on real Cell hardware.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61664 91177308-0d34-0410-b5e6-96231b3b80d8
Finalization occurs after all the FunctionPasses in the group have run, which
is clearly not what we want.
This also means that we have to make sure that we apply the right param
attributes when creating a new function.
Also, add a missed optimization: strdup and strndup. NoCapture and
NoAlias return!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61658 91177308-0d34-0410-b5e6-96231b3b80d8
ParseAssemblyString with a specified module would not parse
into the module, it would create and return a new one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61635 91177308-0d34-0410-b5e6-96231b3b80d8
llvm::PATypeHolder::get() method when LLVM is self-hosted in Release
mode. Before the parser changed, there was a definition of llvm::PAHolder::get()
in llvmAsmParser.y. This was probably a bug that no-one noticed.
Explicitly #include the Type.h file as a temporary fix for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61620 91177308-0d34-0410-b5e6-96231b3b80d8
instructions to avoid copies, because TwoAddressInstructionPass
also does this optimization. The scheduler's version didn't
account for live-out values, which resulted in spurious commutes
and missed opportunities.
Now, TwoAddressInstructionPass handles all the opportunities,
instead of just those that the scheduler missed. The result is
usually the same, though there are occasional trivial differences
resulting from the avoidance of spurious commutes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61611 91177308-0d34-0410-b5e6-96231b3b80d8
- Remove custom lowering for BRCOND
- Add remaining functionality for branches in SPUInstrInfo, such as branch
condition reversal and load/store folding. Updated BrCond test to reflect
branch reversal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61597 91177308-0d34-0410-b5e6-96231b3b80d8
not have pointer type. In particular, it may
be the condition argument for a select or a GEP
index. While I was unable to construct a testcase
for which some bits of the original pointer are
captured due to one of these, it's very very close
to being possible - so play safe and exclude these
possibilities.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61580 91177308-0d34-0410-b5e6-96231b3b80d8
the argument to be stored to an alloca by tracking uses
of the alloca. This occurs 4 times (out of 7121, 0.05%)
in MultiSource/Applications, so may not be worth it. On
the other hand, it is easy to do and fairly cheap. The
functions it helps are: W_addcom and W_addlit in spiff;
process_args (argv) in d (make_dparser); ercPixConcealIMB
in JM/ldecod.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61570 91177308-0d34-0410-b5e6-96231b3b80d8
and clean recursive descent parser.
This change has a couple of ramifications:
1. The parser code is about 400 lines shorter (in what we maintain, not
including what is autogenerated).
2. The code should be significantly faster than the old code because we
don't have to work around bison's poor handling of datatypes with
ctors/dtors. This also makes the code much more resistant to memory
leaks.
3. We now get caret diagnostics from the .ll parser, woo.
4. The actual diagnostics emited from the parser are completely different
so a bunch of testcases had to be updated.
5. I now disallow "%ty = type opaque %ty = type i32". There was no good
reason to support this, it was just an accident of the old
implementation. I have no reason to think that anyone is actually using
this.
6. The syntax for sticking a global variable has changed to make it
unambiguous. I don't think anyone is depending on this since only clang
supports this and it is not solid yet, so I'm not worried about anything
breaking.
7. This gets rid of the last use of bison, and along with it the .cvs files.
I'll prune this from the makefiles as a subsequent commit.
There are a few minor cleanups that can be done after this commit (suggestions
welcome!) but this passes dejagnu testing and is ready for its time in the
limelight.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61558 91177308-0d34-0410-b5e6-96231b3b80d8
functions that don't write can't leak a pointer except through
the return value, so a void readonly function is implicitly nocapture.
Test these, and add a test that verifies that f1 calling f2 with an
otherwise dead pointer gets both of them marked nocapture.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61552 91177308-0d34-0410-b5e6-96231b3b80d8
promote from i1 all the way up to the canonical SetCC type.
In order to discover an appropriate type to use, pass
MVT::Other to getSetCCResultType. In order to be able to
do this, change getSetCCResultType to take a type as an
argument, not a value (this is also more logical).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61542 91177308-0d34-0410-b5e6-96231b3b80d8
to work out (in a very simplistic way) which function
arguments (pointer arguments only) are only dereferenced
and so do not escape. Mark such arguments 'nocapture'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61525 91177308-0d34-0410-b5e6-96231b3b80d8
instruction sequence and cannot ordinarily be simplified by DAGcombine
into the various target description files or SPUDAGToDAGISel.cpp.
This makes some 64-bit operations legal.
- Eliminate target-dependent ISD enums.
- Update tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61508 91177308-0d34-0410-b5e6-96231b3b80d8
and select instructions doesn't buy anything here
except extra complexity: the only difference in
the entire testsuite was that a readonly function
became readnone in MiBench/consumer-typeset. Add
a comment about this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61478 91177308-0d34-0410-b5e6-96231b3b80d8
constants, since doing so is irrelevant for aliasing
purposes. While this doesn't increase the total number
of functions marked readonly or readnone in MultiSource/
Applications (3089), it does result in 12 functions being
marked readnone rather than readonly.
Before:
readnone: 820
readonly: 2269
After:
readnone: 832
readonly: 2257
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61469 91177308-0d34-0410-b5e6-96231b3b80d8
- Move v4i32, i32 mul into SPUInstrInfo.td, with a few more instruction
cleanups there as well.
- Make SMUL_LOHI, UMUL_LOHI competely illegal for Cell SPU, to better
assist Chris to see the problem in bug 3101.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61464 91177308-0d34-0410-b5e6-96231b3b80d8
DAGcombine's ability to find reasons to remove truncates when they were not
needed. Consequently, the CellSPU backend would produce correct, but _really
slow and horrible_, code.
Replaced with instruction sequences that do the equivalent truncation in
SPUInstrInfo.td.
- Re-examine how unaligned loads and stores work. Generated unaligned
load code has been tested on the CellSPU hardware; see the i32operations.c
and i64operations.c in CodeGen/CellSPU/useful-harnesses. (While they may be
toy test code, it does prove that some real world code does compile
correctly.)
- Fix truncating stores in bug 3193 (note: unpack_df.ll will still make llc
fault because i64 ult is not yet implemented.)
- Added i64 eq and neq for setcc and select/setcc; started new instruction
information file for them in SPU64InstrInfo.td. Additional i64 operations
should be added to this file and not to SPUInstrInfo.td.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61447 91177308-0d34-0410-b5e6-96231b3b80d8
other SPEC breakage. I'll be reverting all recent
changes shortly, this checking is mostly so this
change doesn't get lost.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61402 91177308-0d34-0410-b5e6-96231b3b80d8
This removes all the _8, _16, _32, and _64 opcodes and replaces each
group with an unsuffixed opcode. The MemoryVT field of the AtomicSDNode
is now used to carry the size information. In tablegen, the size-specific
opcodes are replaced by size-independent opcodes that utilize the
ability to compose them with predicates.
This shrinks the per-opcode tables and makes the code that handles
atomics much more concise.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61389 91177308-0d34-0410-b5e6-96231b3b80d8
several places. isTerminator() returns true for a superset
of cases, and includes things like FP_REG_KILL, which are
nither return or branch but aren't safe to move/remat/etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61373 91177308-0d34-0410-b5e6-96231b3b80d8
my last patch to this file.
The issue there was that all uses of an IV inside a loop
are actually references to Base[IV*2], and there was one
use outside that was the same but LSR didn't see the base
or the scaling because it didn't recurse into uses outside
the loop; thus, it used base+IV*scale mode inside the loop
instead of pulling base out of the loop. This was extra bad
because register pressure later forced both base and IV into
memory. Doing that recursion, at least enough
to figure out addressing modes, is a good idea in general;
the change in AddUsersIfInteresting does this. However,
there were side effects....
It is also possible for recursing outside the loop to
introduce another IV where there was only 1 before (if
the refs inside are not scaled and the ref outside is).
I don't think this is a common case, but it's in the testsuite.
It is right to be very aggressive about getting rid of
such introduced IVs (CheckForIVReuse and the handling of
nonzero RewriteFactor in StrengthReduceStridedIVUsers).
In the testcase in question the new IV produced this way
has both a nonconstant stride and a nonzero base, neither
of which was handled before. And when inserting
new code that feeds into a PHI, it's right to put such
code at the original location rather than in the PHI's
immediate predecessor(s) when the original location is outside
the loop (a case that couldn't happen before)
(RewriteInstructionToUseNewBase); better to avoid making
multiple copies of it in this case.
Also, the mechanism for keeping SCEV's corresponding to GEP's
no longer works, as the GEP might change after its SCEV
is remembered, invalidating the SCEV, and we might get a bad
SCEV value when looking up the GEP again for a later loop.
This also couldn't happen before, as we weren't recursing
into GEP's outside the loop.
I owe some testcases for this, want to get it in for nightly runs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61362 91177308-0d34-0410-b5e6-96231b3b80d8
constant shift count that doesn't fit in the shift instruction's
immediate field. This fixes PR3242.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61281 91177308-0d34-0410-b5e6-96231b3b80d8
172 %ECX<def> = MOV32rr %reg1039<kill>
180 INLINEASM <es:subl $5,$1
sbbl $3,$0>, 10, %EAX<def>, 14, %ECX<earlyclobber,def>, 9, %EAX<kill>,
36, <fi#0>, 1, %reg0, 0, 9, %ECX<kill>, 36, <fi#1>, 1, %reg0, 0
188 %EAX<def> = MOV32rr %EAX<kill>
196 %ECX<def> = MOV32rr %ECX<kill>
204 %ECX<def> = MOV32rr %ECX<kill>
212 %EAX<def> = MOV32rr %EAX<kill>
220 %EAX<def> = MOV32rr %EAX
228 %reg1039<def> = MOV32rr %ECX<kill>
The early clobber operand ties ECX input to the ECX def.
The live interval of ECX is represented as this:
%reg20,inf = [46,47:1)[174,230:0) 0@174-(230) 1@46-(47)
The right way to represent this is something like
%reg20,inf = [46,47:2)[174,182:1)[181:230:0) 0@174-(182) 1@181-230 @2@46-(47)
Of course that won't work since that means overlapping live ranges defined by two val#.
The workaround for now is to add a bit to val# which says the val# is redefined by a early clobber def somewhere. This prevents the move at 228 from being optimized away by SimpleRegisterCoalescing::AdjustCopiesBackFrom.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61259 91177308-0d34-0410-b5e6-96231b3b80d8
that have i32 immediates so that they get selected first. This
currently only matters in the JIT, as assemblers will
automatically use the smallest encoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61250 91177308-0d34-0410-b5e6-96231b3b80d8
- Use SplitBlockPredecessors to factor out common predecessors of the critical edge destination. This is disabled for now due to some regressions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61248 91177308-0d34-0410-b5e6-96231b3b80d8
The EH_frame and .eh symbols are now private, except for darwin9 and earlier.
The patch also fixes the definition of PrivateGlobalPrefix on pcc linux.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61242 91177308-0d34-0410-b5e6-96231b3b80d8
The problematic part of this patch is that we were out of attribute bits,
requiring some fancy bit hacking to make it fit (by shrinking alignment)
without breaking existing users or the file format.
This change will require users to rebuild llvm-gcc to match llvm.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61239 91177308-0d34-0410-b5e6-96231b3b80d8
folding's tail merging doesn't currently preserve liveness information
which post-RA scheduling requires.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61183 91177308-0d34-0410-b5e6-96231b3b80d8
and the RegisterScavenger not to expect traditional liveness
techniques are applicable to these registers, since we don't fully
modify the effects of push and pop after stackification.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61179 91177308-0d34-0410-b5e6-96231b3b80d8
my last patch to this file.
The issue there was that all uses of an IV inside a loop
are actually references to Base[IV*2], and there was one
use outside that was the same but LSR didn't see the base
or the scaling because it didn't recurse into uses outside
the loop; thus, it used base+IV*scale mode inside the loop
instead of pulling base out of the loop. This was extra bad
because register pressure later forced both base and IV into
memory. Doing that recursion, at least enough
to figure out addressing modes, is a good idea in general;
the change in AddUsersIfInteresting does this. However,
there were side effects....
It is also possible for recursing outside the loop to
introduce another IV where there was only 1 before (if
the refs inside are not scaled and the ref outside is).
I don't think this is a common case, but it's in the testsuite.
It is right to be very aggressive about getting rid of
such introduced IVs (CheckForIVReuse and the handling of
nonzero RewriteFactor in StrengthReduceStridedIVUsers).
In the testcase in question the new IV produced this way
has both a nonconstant stride and a nonzero base, neither
of which was handled before. (This patch does not handle
all the cases where this can happen.) And when inserting
new code that feeds into a PHI, it's right to put such
code at the original location rather than in the PHI's
immediate predecessor(s) when the original location is outside
the loop (a case that couldn't happen before)
(RewriteInstructionToUseNewBase); better to avoid making
multiple copies of it in this case.
Everything above is exercised in
CodeGen/X86/lsr-negative-stride.ll (and ifcvt4 in ARM which is
the same IR).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61178 91177308-0d34-0410-b5e6-96231b3b80d8
First step to resolve this is, record file name and directory directly in debug info for various debug entities.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61164 91177308-0d34-0410-b5e6-96231b3b80d8
- ability to insert previously created instructions using a builder
- creation of aliases
- creation of inline asm constants
Patch by Zoltan Varga!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61153 91177308-0d34-0410-b5e6-96231b3b80d8
nodes. This allows it to do fairly general phi insertion if a
load from a pointer global wants to be SRAd but the load is used
by (recursive) phi nodes. This fixes a pessimization on ppc
introduced by Load PRE.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61123 91177308-0d34-0410-b5e6-96231b3b80d8
temporary workaround for an obscure bug. When node cloning is
used, it is possible that more SUnits will be created, and
if the SUnits std::vector has to reallocate, it will
invalidate all the graph edges.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61122 91177308-0d34-0410-b5e6-96231b3b80d8
DAGTypeLegalizer::ExpandShiftWithKnownAmountBit.
In terms of restoring the optimization, the best fix here isn't
obvious... any ideas?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61119 91177308-0d34-0410-b5e6-96231b3b80d8
can be negative. Keep track of whether all uses of
an IV are outside the loop. Some cosmetics; no
functional change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61109 91177308-0d34-0410-b5e6-96231b3b80d8
