This removes a redundant stride versioning step (we already
do it in getPtrStride, so it has no effect) and uses PSE to
get the SCEV expressions for the source and destination
(this might have changed when getPtrStride was called).
I discovered this through code inspection, and couldn't
produce a regression test for it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269052 91177308-0d34-0410-b5e6-96231b3b80d8
This was a fairly simple patch but on closer inspection was seriously flawed and caused PR27690.
This reverts commit r268921.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269051 91177308-0d34-0410-b5e6-96231b3b80d8
Following post-commit comments on r268900 from Rafael Espindola:
The missing relocations are now explicitly listed in the switch statement with
appropriate FIXME comments and the default path is now unreachable. The
temporary exception to this is that compound relocations for N64 still have a
default path that returns true. This is because fixing that case ought to be a
separate patch.
Also make R_MIPS_NONE return false since it has no effect on the section data.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269047 91177308-0d34-0410-b5e6-96231b3b80d8
Loop rotation clones instruction from the old header into the preheader. If
there were uses of values produced by these instructions that were outside
the loop, we have to insert PHI nodes to merge the two values. If the values
are used by DbgIntrinsics they will be used as a MetadataAsValue of a
ValueAsMetadata of the original values, and iterating all of the uses of the
original value will not update the DbgIntrinsics. The new code checks if the
values are used by DbgIntrinsics and if so, updates them using essentially
the same logic as the original code.
The attached testcase demonstrates the issue. Without the fix, the
DbgIntrinic outside the loop uses values computed inside the loop, even
though these values do not dominate the DbgIntrinsic.
Author: Thomas Jablin (tjablin)
Reviewers: dblaikie aprantl kbarton hfinkel cycheng
http://reviews.llvm.org/D19564
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269034 91177308-0d34-0410-b5e6-96231b3b80d8
When a va_start or va_copy is immediately followed by a va_end (ignoring
debug information or other start/end in between), then it is safe to
remove the pair. As this code shares some commonalities with the lifetime
markers, this has been factored to helper functions.
This InstCombine pattern kicks-in 3 times when running the LLVM test
suite.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269033 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commits r268969, r268979 and r268984. They had target specific test
in generic directories without the correct specifiers and made it hard for us to
come up with a good solution by rapidly committing untested changes.
This test needs to be in a target specific directory or have the correct REQUIRED
identifier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269027 91177308-0d34-0410-b5e6-96231b3b80d8
SystemZ (and probably other targets as well) can fold a memory operand
by changing the opcode into a new instruction that as a side-effect
also clobbers the CC-reg.
In order to do this, liveness of that reg must first be checked. When
LIS is passed, getRegUnit() can be called on it and the right
LiveRange is computed on demand.
Reviewed by Matthias Braun.
http://reviews.llvm.org/D19861
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269026 91177308-0d34-0410-b5e6-96231b3b80d8
Allow vectorization when the step is a loop-invariant variable.
This is the loop example that is getting vectorized after the patch:
int int_inc;
int bar(int init, int *restrict A, int N) {
int x = init;
for (int i=0;i<N;i++){
A[i] = x;
x += int_inc;
}
return x;
}
"x" is an induction variable with *loop-invariant* step.
But it is not a primary induction. Primary induction variable with non-constant step is not handled yet.
Differential Revision: http://reviews.llvm.org/D19258
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269023 91177308-0d34-0410-b5e6-96231b3b80d8
We now use LiveRangeCalc::extendToUses() instead of a specially designed
algorithm in constructMainRangeFromSubranges():
- The original motivation for constructMainRangeFromSubranges() were
differences between the main liverange and subranges because of hidden
dead definitions. This case however cannot happen anymore with the
DetectDeadLaneMasks pass in place.
- It simplifies the code.
- This fixes a longstanding bug where we did not properly create new SSA
values on merging control flow (the MachineVerifier missed most of
these cases).
- Move constructMainRangeFromSubranges() to LiveIntervalAnalysis and
LiveRangeCalc to better match the implementation/available helper
functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269016 91177308-0d34-0410-b5e6-96231b3b80d8
In -run-pass mode verify/print machine function immediately after
loading the .mir file if -verify-machineinstr/-print-machineinstrs
option is specified.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269014 91177308-0d34-0410-b5e6-96231b3b80d8
Move the register stackification and coloring passes to run very late, after
PEI, tail duplication, and most other passes. This means that all code emitted
and expanded by those passes is now exposed to these passes. This also
eliminates the need for prologue/epilogue code to be manually stackified,
which significantly simplifies the code.
This does require running LiveIntervals a second time. It's useful to think
of these late passes not as late optimization passes, but as a domain-specific
compression algorithm based on knowledge of liveness information. It's used to
compress the code after all conventional optimizations are complete, which is
why it uses LiveIntervals at a phase when actual optimization passes don't
typically need it.
Differential Revision: http://reviews.llvm.org/D20075
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269012 91177308-0d34-0410-b5e6-96231b3b80d8
Many files include Passes.h but only a fraction needs to know about the
TargetPassConfig class. Move it into an own header. Also rename
Passes.cpp to TargetPassConfig.cpp while we are at it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269011 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The idea is very close to what we do for assume intrinsics: we mark the
guard intrinsics as writing to arbitrary memory to maintain control
dependence, but under the covers we teach AA that they do not mod any
particular memory location.
Reviewers: chandlerc, hfinkel, gbiv, reames
Subscribers: george.burgess.iv, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D19575
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269007 91177308-0d34-0410-b5e6-96231b3b80d8
Looks like you need the complete definition of "X" when calling a "X
&func()" declared function even when not using the result further.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269006 91177308-0d34-0410-b5e6-96231b3b80d8
We now construct a custom pass pipeline instead of injecting
start-before/stop-after into the default pipeline construction. This
allows to specify any pass known to the pass registry. Previously
specifying indirectly added analysis passes or passes not added to the
pipeline add all would not be added and we would silently do nothing.
This also restricts the -run-pass option to cases with .mir input.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269003 91177308-0d34-0410-b5e6-96231b3b80d8
Add convenience function to create MachineModuleInfo and
MachineFunctionAnalysis passes and add them to a pass manager.
Despite factoring out some shared code in
LiveIntervalTest/LLVMTargetMachine this will be used by my upcoming llc
change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269002 91177308-0d34-0410-b5e6-96231b3b80d8
When loading or storing AVX512 registers we were not using the AVX512
variant of the load and store for VR128 and VR256 like registers.
Thus, we ended up with the wrong encoding and actually were dropping the
high bits of the instruction. The result was that we load or store the
wrong register. The effect is visible only when we emit the object file
directly and disassemble it. Then, the output of the disassembler does
not match the assembly input.
This is related to llvm.org/PR27481.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@269001 91177308-0d34-0410-b5e6-96231b3b80d8
We can use calls to @llvm.experimental.guard to prove predicates,
relying on the fact that in all locations domianted by a call to
@llvm.experimental.guard the predicate it is guarding is known to be
true.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268997 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously these intrinsics were marked as can-read any memory address.
Now they're marked as reading only the pointer they're passed.
Reviewers: rnk
Subscribers: jholewinski, llvm-commits, tra
Differential Revision: http://reviews.llvm.org/D20080
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268996 91177308-0d34-0410-b5e6-96231b3b80d8
Previously it was just "// inline asm", which made it tricky to read
code with lots of inline assembly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268994 91177308-0d34-0410-b5e6-96231b3b80d8
Currently the signature of the functions
i128(i128, i32) aka void(i32, i64, i64, i32) doesn't match the signature
of the call emitted by the default lowering, void(i32, i64, i64).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268991 91177308-0d34-0410-b5e6-96231b3b80d8
The call to Select on Upper here happens in an unusual order in order
to defeat the constant folding that getNode() does. Add a comment
explaining why we can't just move the Select to later to avoid a
Handle, and wrap the call to SelectCode in a handle so we don't need
its return value.
This is part of the work to have Select return void instead of an
SDNode *, which is in turn part of llvm.org/pr26808.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268990 91177308-0d34-0410-b5e6-96231b3b80d8
When we encounter unsafe memory dependencies, loop distribution could
help.
Even though, the diagnostics is in LAA, it's only currently emitted in
the vectorizer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268987 91177308-0d34-0410-b5e6-96231b3b80d8
We used to list registers that were not in the AVX space. In other
words, we were pushing registers that the ISA cannot encode
(YMM16-YMM31).
This is part of llvm.org/PR27481.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268983 91177308-0d34-0410-b5e6-96231b3b80d8
