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
When undoing a reuse in ReuseInfo::GetRegForReload, check if it was only a
sub-register being used. The MachineOperand::getSubReg() method is only valid
for virtual registers, so we have to recover the sub-register index manually.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79855 91177308-0d34-0410-b5e6-96231b3b80d8
- Honor .globl.
- Set symbol type and section correctly ('nm' now works), and order symbols
appropriately.
- Take care to the string table so that the .o matches 'as' exactly (for ease
of testing).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79740 91177308-0d34-0410-b5e6-96231b3b80d8
(external was really undefined and there wasn't an explicit representation for
absolute symbols).
- This still needs some cleanup to how the absolute "pseudo" section is dealt
with, but I haven't figured out the nicest approach yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79733 91177308-0d34-0410-b5e6-96231b3b80d8
(e.g., .objc_message_refs).
- Just emit a .align when we see the directive; this isn't exactly what 'as'
does but in practice it should be ok, at least for now. See FIXME.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79697 91177308-0d34-0410-b5e6-96231b3b80d8
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
vector shuffles. Temporarily remove the tests for these operations until the
new implementation is working.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79579 91177308-0d34-0410-b5e6-96231b3b80d8
over absolute addressing even in non-PIC mode (unless the address
has an index or something else incompatible), because it has a
smaller encoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79553 91177308-0d34-0410-b5e6-96231b3b80d8
array member of a struct, it's possible to land in an arbitrary position
inside that struct, such that attempting to find further getelementptr
indices will fail. In such cases, folding cannot be done.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79485 91177308-0d34-0410-b5e6-96231b3b80d8
static extents of the static array type, it causes GlobalOpt and
other passes to be more conservative. This canonicalization also
allows the constant folder to add "inbounds" to GEPs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79440 91177308-0d34-0410-b5e6-96231b3b80d8
This is derived from a patch by Anton Korzh. I modified it to recognize
the VEXT shuffles during legalization and lower them to a target-specific
DAG node.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79428 91177308-0d34-0410-b5e6-96231b3b80d8
TargetData is not present. It still uses TargetData when available.
This generalization also fixed some limitations in the TargetData
case; the attached testcase covers this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79344 91177308-0d34-0410-b5e6-96231b3b80d8
remove RemoveDuplicateSuccessor, as it is no longer necessary, and because
it breaks assumptions made in
MachineBasicBlock::isOnlyReachableByFallthrough.
Convert test/CodeGen/X86/omit-label.ll to FileCheck and add a testcase
for PR4732.
test/CodeGen/Thumb2/thumb2-ifcvt2.ll sees a diff with this commit due to
it being bugpoint-reduced to the point where it doesn't matter what the
condition for the branch is.
Add some more interesting code to
test/CodeGen/X86/2009-08-06-branchfolder-crash.ll, which is the testcase
that originally motivated the RemoveDuplicateSuccessor code, to help
verify that the original problem isn't being re-broken.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79338 91177308-0d34-0410-b5e6-96231b3b80d8
try to use i686-darwin to build for arm-eabi, you'll quickly run into
several false assumptions that the target OS must be the same as the
host OS. These patches split $(OS) into $(HOST_OS) and $(TARGET_OS) to
help builds like "make check" and the test-suite able to cross
compile. Along the way a target of *-unknown-eabi is defined as
"Freestanding" so that TARGET_OS checks have something to work with.
Patch by Sandeep Patel!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79296 91177308-0d34-0410-b5e6-96231b3b80d8
for a single "m" constraint; this is wrong because the
opcode of a load or store would have to change in parallel.
This patch makes it always compute addresses into a register,
which is correct but not as efficient as possible. 7144566.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79292 91177308-0d34-0410-b5e6-96231b3b80d8
unfoldable references to a PHI node in the block being folded, and disable
the transformation in that case. The correct transformation of such PHI
nodes depends on whether BB dominates Succ, and dominance is expensive
to compute here. (Alternatively, it's possible to check whether any
uses are live, but that's also essentially a dominance calculation.
Another alternative is to use reg2mem, but it probably isn't a good idea to
use that in simplifycfg.)
Also, remove some incorrect code from CanPropagatePredecessorsForPHIs
which is made unnecessary with this patch: it didn't consider the case
where a PHI node in BB has multiple uses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79174 91177308-0d34-0410-b5e6-96231b3b80d8
support unaligned mem access only for certain types. (Should it be size
instead?)
ARM v7 supports unaligned access for i16 and i32, some v6 variants support it
as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79127 91177308-0d34-0410-b5e6-96231b3b80d8
