This was originally introduced in r278321 to work around correctness
problems in the ExecutionDepsFix pass; Probably also to keep the
performance benefits of breaking the false dependencies which of course
also affect undef operands.
ExecutionDepsFix has been improved here recently (see for example
r278321) so we should not need this exception any longer.
Differential Revision: https://reviews.llvm.org/D29525
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294087 91177308-0d34-0410-b5e6-96231b3b80d8
Move a check for blocks that are not candidates for tail duplication up before
the logging. Reduces logging noise. No non-logging changes intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294086 91177308-0d34-0410-b5e6-96231b3b80d8
Anything that needs to be passed to AnalyzeBranch unfortunately can't be const,
or more would be const. Added const_iterator to BlockChain to allow
BlockChain to be const when we don't expect to change it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294085 91177308-0d34-0410-b5e6-96231b3b80d8
This lets us split out PatternToMatch from the top-level RuleMatcher,
where it doesn't really belong. That, in turn, lets us eventually
generate RuleMatchers from non-SelectionDAG sources.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294076 91177308-0d34-0410-b5e6-96231b3b80d8
We don't try very hard to format the emitted code, but newlines
are an easy way to make it more readable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294074 91177308-0d34-0410-b5e6-96231b3b80d8
An assert occurs when calling SlotIndexes::getInstructionIndex with
a DBG_VALUE instruction because the function expects an instruction
with a slot index. However, there is no slot index for a DBG_VALUE
instruction.
Differential Revision: https://reviews.llvm.org/D29048
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294070 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is based on the llvm-dev discussion here:
http://lists.llvm.org/pipermail/llvm-dev/2017-January/109631.html
Folding to i1 should always be desirable because that's better for value tracking
and we have special folds for i1 types.
I checked for other users of shouldChangeType() where this might have an effect,
but we already handle the i1 case differently than other types in all of those cases.
Side note: the default datalayout includes i1, so it seems we only find this gap in
shouldChangeType + phi folding for the case when there is (1) an explicit datalayout
without i1, (2) casting to i1 from a legal type, and (3) a phi with exactly 2 incoming
casted operands (as Björn mentioned).
Differential Revision: https://reviews.llvm.org/D29336
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294066 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: As per title. I ran into that limitation of the API doing some other work, so I though that'd be a nice addition.
Reviewers: jroelofs, compnerd, majnemer
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29503
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294063 91177308-0d34-0410-b5e6-96231b3b80d8
The code comments didn't match the code logic, and we didn't actually distinguish the fake unary (not/neg/fneg)
operators from arguments. Adding another level to the weighting scheme provides more structure and can help
simplify the pattern matching in InstCombine and other places.
I fixed regressions that would have shown up from this change in:
rL290067
rL290127
But that doesn't mean there are no pattern-matching logic holes left; some combines may just be missing regression tests.
Should fix:
https://llvm.org/bugs/show_bug.cgi?id=28296
Differential Revision: https://reviews.llvm.org/D27933
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294049 91177308-0d34-0410-b5e6-96231b3b80d8
This has quite positive performance impact according to measurements.
Before previous fixes to limit the optimization that was too high
and blowed compile time and scratch usage, but now this is gone and
we can bump the threshold.
Differential Revision: https://reviews.llvm.org/D29505
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294032 91177308-0d34-0410-b5e6-96231b3b80d8
This re-applies commit r292189, reverted in r292191.
SelectionDAGBuilder recognizes libfuncs using some homegrown
parameter type-checking.
Use TLI instead, removing another heap of redundant code.
This isn't strictly NFC, as the SDAG code was too lax.
Concretely, this means changes are required to a few tests:
- calling a non-variadic function via a variadic prototype isn't OK;
it just happens to work on x86_64 (but not on, e.g., aarch64).
- mempcpy has a size_t parameter; the SDAG code accepts any integer
type, which meant using i32 on x86_64 worked.
- a handful of SystemZ tests check the SDAG support for lax prototype
checking: Ulrich agrees on removing them.
I don't think it's worth supporting any of these (IMO) invalid
testcases. Instead, fix them to be more meaningful.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294028 91177308-0d34-0410-b5e6-96231b3b80d8
This generalizes memory access sorting to use differences between SCEVs,
instead of relying on constant offsets. That allows us to properly do
SLP vectorization of non-sequentially ordered loads within loops bodies.
Differential Revision: https://reviews.llvm.org/D29425
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294027 91177308-0d34-0410-b5e6-96231b3b80d8
Make it clear these tests sign-extend the comparison result. Some patterns zero-extend to a bool result that we still need to handle.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294018 91177308-0d34-0410-b5e6-96231b3b80d8
The importer was previously using ModuleLinker in a sort of "IRMover mode". Use
IRMover directly instead in order to remove a level of indirection.
I will remove all importing support from ModuleLinker in a separate
change.
Differential Revision: https://reviews.llvm.org/D29468
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294014 91177308-0d34-0410-b5e6-96231b3b80d8
The .end <symbol> directive for MIPS marks the end of a symbol and sets the
symbol's size. Previously, the corresponding emitDirective handler asserted
that a function's size could be evaluated to an absolute value at that point
in time.
This cannot be done with when directives like .align have been encountered,
instead set the function's size to the corresponding symbolic expression and
let ELFObjectWriter resolve the expression to an absolute value. This avoids
a redundant call to evaluateAsAbsolute.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@294012 91177308-0d34-0410-b5e6-96231b3b80d8
