loop exit edge -- new PHIs may be needed not only for the additional
splits that are made to preserve LoopSimplify form, but also for the
original split. Factor out the code that inserts new PHIs so that it
can be used for both. Remove LoopRotation.cpp's code for manually
updating LCSSA form, as it is now redundant. This fixes PR4934.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81363 91177308-0d34-0410-b5e6-96231b3b80d8
to instructions instead of zero extended ones. This makes the asmprinter
print signed values more consistently. This apparently only really affects
the X86 backend.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81265 91177308-0d34-0410-b5e6-96231b3b80d8
that get created during loop unswitching, and fix SplitBlockPredecessors'
LCSSA updating code to create new PHIs instead of trying to just move
existing ones.
Also, optimize Loop::verifyLoop, since it gets called a lot. Use
searches on a sorted list of blocks instead of calling the "contains"
function, as is done in other places in the Loop class, since "contains"
does a linear search. Also, don't call verifyLoop from LoopSimplify or
LCSSA, as the PassManager is already calling verifyLoop as part of
LoopInfo's verifyAnalysis.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81221 91177308-0d34-0410-b5e6-96231b3b80d8
depth first order, so it wouldn't process unreachable blocks.
When compiling at -O0, late dead block elimination isn't done
and the bad instructions got to isel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81187 91177308-0d34-0410-b5e6-96231b3b80d8
extractelement operations into a bitcast of the pointer,
then a gep, then a scalar load. Disable this when the vector
only has one element, because it leads to infinite loops in
instcombine (PR4908).
This transformation seems like a really bad idea to me, as it
will likely disable CSE of vector load/stores etc and can be
better done in the code generator when profitable. This
goes all the way back to the first days of packed types,
r25299 specifically.
I'll let those people who care about the performance of vector
code decide what to do with this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81185 91177308-0d34-0410-b5e6-96231b3b80d8
from floating-point to integer first, and bitcast the result
back to floating-point. Previously, this test was passing by
falling back to SelectionDAG lowering. The resulting code isn't
as nice, but it's correct and CodeGen now stays on the fast path.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81171 91177308-0d34-0410-b5e6-96231b3b80d8
- I'd appreciate it if someone else eyeballs my changes to make sure I captured
the intent of the test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81083 91177308-0d34-0410-b5e6-96231b3b80d8
linear scan reg alloc. This fixes a problem I ran into where extracting
a function from a larger file caused the generated code to change (masking
the problem I was trying to debug) because the allocator behaved differently.
This changes the results for two X86 regression checks. stack-color-with-reg
is improved, with one less instruction, but pr3495 is worse, with one more
copy. As far as I can tell, these tests were just getting lucky or unlucky,
so I've changed the expected results.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81060 91177308-0d34-0410-b5e6-96231b3b80d8
Constant uniquing tables. This allows distinct ConstantExpr objects
with the same operation and different flags.
Even though a ConstantExpr "a + b" is either always overflowing or
never overflowing (due to being a ConstantExpr), it's still necessary
to be able to represent it both with and without overflow flags at
the same time within the IR, because the safety of the flag may
depend on the context of the use. If the constant really does overflow,
it wouldn't ever be safe to use with the flag set, however the use
may be in code that is never actually executed.
This also makes it possible to merge all the flags tests into a single test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80998 91177308-0d34-0410-b5e6-96231b3b80d8
There's a bug with ocamlc that uses "char*" instead of "const char*" for
global string variables. This causes g++ to be very noisy when linking
ocamlc programs. That's why the ocaml test used to cat to /dev/null.
ocamlopt doesn't have this problem, so we can get rid of the >/dev/null,
which may obscure some problems.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80968 91177308-0d34-0410-b5e6-96231b3b80d8
D test/Analysis/Profiling
--- Reverse-merging r80907 into '.':
U lib/Analysis/ProfileInfoLoaderPass.cpp
Attempt to remove failure in the self-hosting build bot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80966 91177308-0d34-0410-b5e6-96231b3b80d8
on a self-hosted build (although it seems to work on non-self hosted). I'll work
with Andreas to figure this out.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80947 91177308-0d34-0410-b5e6-96231b3b80d8
instead of a bool argument, and to do the dominator check itself.
This makes it eaiser to use when DominatorTree information is
available.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80920 91177308-0d34-0410-b5e6-96231b3b80d8
simplifylibcalls optimization is thus valid for C++ but not C.
It's not important enough to worry about for C++ apps, so just
remove it.
rdar://7191924
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80887 91177308-0d34-0410-b5e6-96231b3b80d8
edge-profiling, this is more useful since the loading of the
optimal-edge-profiling is more complicated.
The edge-profiling is tested in edge-profiling.ll where only the
instrumentation is tested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80791 91177308-0d34-0410-b5e6-96231b3b80d8
and we get the original pointer type. This doesn't mean that we're
at the first pointer being indexed. Correct the predicate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80762 91177308-0d34-0410-b5e6-96231b3b80d8
don't alias. Remove an old and poorly reduced testcase that fails
with this transform for reasons unrelated to the original test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80693 91177308-0d34-0410-b5e6-96231b3b80d8
for sanity. This didn't turn up any bugs.
Change CallGraphNode to maintain its "callsite" information in the
call edges list as a WeakVH instead of as an instruction*. This fixes
a broad class of dangling pointer bugs, and makes CallGraph have a number
of useful invariants again. This fixes the class of problem indicated
by PR4029 and PR3601.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80663 91177308-0d34-0410-b5e6-96231b3b80d8
tied to different source registers, the TwoAddressInstructionPass needs to
be smarter. Change it to check before replacing a source register whether
that source register is tied to a different destination register, and if so,
defer handling it until a subsequent iteration.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80654 91177308-0d34-0410-b5e6-96231b3b80d8
makes an eggregious hack somewhat more palatable. Bringing the LSDA forward
and making it a GV available for reference would be even better, but is
beyond the scope of what I'm looking to solve at this point.
Objective C++ code could generate function names that broke the previous
scheme. This fixes that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80649 91177308-0d34-0410-b5e6-96231b3b80d8
changes: SimplifyDemandedBits can't use the builder yet because it
has the wrong insertion point. This fixes a crash building
MultiSource/Benchmarks/PAQ8p
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80537 91177308-0d34-0410-b5e6-96231b3b80d8
indirect function pointer, inline it, then go to delete the body.
The problem is that the callgraph had other references to the function,
though the inliner had no way to know it, so we got a dangling pointer
and an invalid iterator out of the deal.
The fix to this is pretty simple: stop the inliner from deleting the
function by knowing that there are references to it. Do this by making
CallGraphNodes contain a refcount. This requires moving deletion of
available_externally functions to the module-level cleanup sweep where
it belongs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80533 91177308-0d34-0410-b5e6-96231b3b80d8
is itself a bitcast. Since we have gep(bitcast(bitcast(y))) in this
case, just wait for the two bitcasts to get zapped. This prevents
instcombine from confusing some aliasing stuff, and allows it to
directly eliminate the load in the testcase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80508 91177308-0d34-0410-b5e6-96231b3b80d8
make check in a non-clean directory causes it to fail (for example when running
make check twice), since execution counts will differ.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80362 91177308-0d34-0410-b5e6-96231b3b80d8
- I'm still trying to figure out the cleanest way to implement this and match the assembler, currently there are some substantial differences.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80347 91177308-0d34-0410-b5e6-96231b3b80d8
calls into a function and if the calls bring in arrays, try to merge
them together to reduce stack size. For example, in the testcase
we'd previously end up with 4 allocas, now we end up with 2 allocas.
As described in the comments, this is not really the ideal solution
to this problem, but it is surprisingly effective. For example, on
176.gcc, we end up eliminating 67 arrays at "gccas" time and another
24 at "llvm-ld" time.
One piece of concern that I didn't look into: at -O0 -g with
forced inlining this will almost certainly result in worse debug
info. I think this is acceptable though given that this is a case
of "debugging optimized code", and we don't want debug info to
prevent the optimizer from doing things anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80215 91177308-0d34-0410-b5e6-96231b3b80d8
moves. This avoids the need to promote the operands (or implicitly
extend them, a partial register update condition), and can reduce
i8 register pressure. This substantially speeds up code such as
write_hex in lib/Support/raw_ostream.cpp.
subclass-coalesce.ll is too trivial and no longer tests what it was
originally intended to test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80184 91177308-0d34-0410-b5e6-96231b3b80d8
sections, etc.
- The quick and dirty way, just clone the TargetLoweringObjectFile
code. Eventually this should be shared... somehow.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80168 91177308-0d34-0410-b5e6-96231b3b80d8
- I moved section creation back into AsmParser. I think policy decisions like
this should be pushed higher, not lower, when possible (in addition the
assembler has flags which change this behavior, for example).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80162 91177308-0d34-0410-b5e6-96231b3b80d8
leads to partial-register definitions. To help avoid redundant
zero-extensions, also teach the h-register matching patterns that
use movzbl to match anyext as well as zext.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80099 91177308-0d34-0410-b5e6-96231b3b80d8
This is a simple AliasAnalysis implementation which works by making
ScalarEvolution queries. ScalarEvolution has a more complete understanding
of arithmetic than BasicAA's collection of ad-hoc checks, so it handles
some cases that BasicAA misses, for example p[i] and p[i+1] within the
same iteration of a loop.
This is currently experimental. It may be that the main use for this pass
will be to help find cases where BasicAA can be profitably extended, or
to help in the development of the overall AliasAnalysis infrastructure,
however it's also possible that it could grow up to become a directly
useful pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80098 91177308-0d34-0410-b5e6-96231b3b80d8
- I haven't really tried to find the "right" way to store the fixups or apply
them, yet. This works, but isn't particularly elegant or fast.
- Still no evaluation support, so we don't actually ever not turn a fixup into
a relocation entry.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80089 91177308-0d34-0410-b5e6-96231b3b80d8
more and is much nicer to the OS.
- Dan, please check. If there are parts of the test you think I should strip
out so it doesn't cause random failures let me know (there are still some PIC
label numbers in it, for example).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80019 91177308-0d34-0410-b5e6-96231b3b80d8
sinking code, since they are special. If the loop preheader happens
to be the entry block of a function, don't sink static allocas
out of it. This fixes PR4775.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80010 91177308-0d34-0410-b5e6-96231b3b80d8
This change speeds up llvm-gcc by more then 6% at "-O0 -g" (measured by compiling InstructionCombining.cpp!)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79977 91177308-0d34-0410-b5e6-96231b3b80d8
code, according to Anton (I'm not totally convinced, but we can always
resurrect patches if we need to do so.)
- Start moving CellSPU's tests to prefer FileCheck.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79958 91177308-0d34-0410-b5e6-96231b3b80d8
- This is mostly complete, the main thing missing is .indirect_symbol support
(which would be straight-forward, except that the way it is implemented in
'as' makes getting an exact .o match interesting).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79899 91177308-0d34-0410-b5e6-96231b3b80d8
all Darwin targets; could be split into separate tests for
the chip subdirectories, but from Chris' last mail on testing
I assume he'd rather have only one test. Generic seems to be
the best available, maybe there should be a Darwin subdirectory?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79877 91177308-0d34-0410-b5e6-96231b3b80d8
