We hitch a ride with the existing OpndItins class that was used to add
instruction itinerary classes in the many multiclasses in this file.
Use the link provided by the X86FoldableSchedWrite.Folded to find the
right SchedWrite for folded loads.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177326 91177308-0d34-0410-b5e6-96231b3b80d8
This new-style scheduling information is going to replace the
instruction iteneraries.
This also serves as a test case for Andy's fix in r177317.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177323 91177308-0d34-0410-b5e6-96231b3b80d8
This handles the case where we have an inbounds GEP with alloca as the pointer.
This fixes the regression in PR12750 and rdar://13286434.
Note that we can also fix this by handling some GEP cases in isKnownNonNull.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177321 91177308-0d34-0410-b5e6-96231b3b80d8
Properly handle cases where a group of instructions have different
SchedRW lists with the same itinerary class.
This was supposed to work, but I left in an early break.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177317 91177308-0d34-0410-b5e6-96231b3b80d8
Apparently my final cleanup to use a relevant suffix for these tests before
committing r176831 caused them to stop running since lit wasn't configured to
run tests with that suffix in those directories (why don't we just have a
global suffix list?). So, add the suffix to the relevant directories & fix the
test that has bitrotted over the last week due to my debug info schema changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177315 91177308-0d34-0410-b5e6-96231b3b80d8
This commit fixes an assert that would occur on loops with large constant counts
(like looping for ((uint32_t) -1) iterations on PPC64). The existing code did
not handle counts that it computed to be negative (asserting instead), but
these can be created with valid inputs.
This bug was discovered by bugpoint while I was attempting to isolate a
completely different problem.
Also, in writing test cases for the negative-count problem, I discovered that
the ori/lsi handling was broken (there was a typo which caused the logic that
was supposed to detect these pairs and extract the iteration count to always
fail). This has now also been corrected (and is covered by one of the new test
cases).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177295 91177308-0d34-0410-b5e6-96231b3b80d8
Because the initial-value constants had not been added to the list
of instructions considered for DCE the resulting code had redundant
constant-materialization instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177294 91177308-0d34-0410-b5e6-96231b3b80d8
The always-true "(int)Int == (signed)Int" comparison was found
while experimenting with a potential new Clang warning.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177290 91177308-0d34-0410-b5e6-96231b3b80d8
we weren't differntiating floating-point zeroinitializers from other zero-initializers)
which was causing problems for code relying upon a + (+0.0f) to, eg, flush denormals to
0. Make the scalar and vector cases have the same behaviour.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177279 91177308-0d34-0410-b5e6-96231b3b80d8
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177277 91177308-0d34-0410-b5e6-96231b3b80d8
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177276 91177308-0d34-0410-b5e6-96231b3b80d8
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177275 91177308-0d34-0410-b5e6-96231b3b80d8
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177274 91177308-0d34-0410-b5e6-96231b3b80d8
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177273 91177308-0d34-0410-b5e6-96231b3b80d8
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177272 91177308-0d34-0410-b5e6-96231b3b80d8
Unfortunately the previous fix for inserting waits for unordered
defines wasn't sufficient, cause it's possible that even ordered
defines are only partially used (or not used at all).
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177271 91177308-0d34-0410-b5e6-96231b3b80d8
MinGW is almost completely compatible to MSVC, with the exception of the _tls_array global not being available.
Patch by David Nadlinger!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177257 91177308-0d34-0410-b5e6-96231b3b80d8
The linker sorts the .tls$<xyz> sections by name, and we need
to make sure any extra sections we produce (e.g. for weak globals)
always end up between .tls$AAA and .tls$ZZZ, even if the name
starts with e.g. an underscore.
Patch by David Nadlinger!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177256 91177308-0d34-0410-b5e6-96231b3b80d8
This computes the type of an instruction operand or result based on the
records in the instruction's ins and outs lists.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177244 91177308-0d34-0410-b5e6-96231b3b80d8
*NOTE* I verified that the original bug behind
dont-infinite-loop-during-block-escape-analysis.ll occurs when using opt on
retain-block-escape-analysis.ll.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177240 91177308-0d34-0410-b5e6-96231b3b80d8
This is the first step to making all DIScopes have a common metadata prefix (so
that things (using directives, for example) that can appear in any scope can be
added to that common prefix). DIFile is itself a DIScope so the common prefix
of all DIScopes cannot be a DIFile - instead it's the raw filename/directory
name pair.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177239 91177308-0d34-0410-b5e6-96231b3b80d8
This test makes sure that the ObjCARC escape analysis looks at the uses of
instructions which copy the block pointer value by checking all four cases where
that can occur.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177232 91177308-0d34-0410-b5e6-96231b3b80d8
This change cleans up two issues with Altivec register spilling:
1. The spilling code was inefficient (using two instructions, and add and a
load, when just one would do)
2. The code assumed that r0 would always be available (true for now, but this
will change)
The new code handles VR spilling just like GPR spills but forced into r+r mode.
As a result, when any VR spills are present, we must now always allocate the
register-scavenger spill slot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177231 91177308-0d34-0410-b5e6-96231b3b80d8
As a follow-up to r158719, remove PPCRegisterInfo::avoidWriteAfterWrite.
Jakob pointed out in response to r158719 that this callback is currently unused
and so this has no effect (and the speedups that I thought that I had observed
as a result of implementing this function must have been noise).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177228 91177308-0d34-0410-b5e6-96231b3b80d8
Implicit defs are not currently positional and not modeled by the
per-operand machine model. Unfortunately, we treat defs that are part
of the architectural instruction description, like flags, the same as
other implicit defs. Really, they should have a fixed MachineInstr
layout and probably shouldn't be "implicit" at all.
For now, we'll change the default latency to be the max operand
latency. That will give flag setting operands full latency for x86
folded loads. Other kinds of "fake" implicit defs don't occur prior to
regalloc anyway, and we would like them to go away postRegAlloc as
well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177227 91177308-0d34-0410-b5e6-96231b3b80d8
We always supported a mixture of the old itinerary model and new
per-operand model, but it required a level of indirection to map
itinerary classes to SchedRW lists. This was done for ARM A9.
Now we want to define x86 SchedRW lists, with the goal of removing its
itinerary classes, but still support the itineraries in the mean
time. When I original developed the model, Atom did not have
itineraries, so there was no reason to expect this requirement.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177226 91177308-0d34-0410-b5e6-96231b3b80d8
Since almost all X86 instructions can fold loads, use a multiclass to
define register/memory pairs of SchedWrites.
An X86FoldableSchedWrite represents the register version of an
instruction. It holds a reference to the SchedWrite to use when the
instruction folds a load.
This will be used inside multiclasses that define rr and rm instruction
versions together.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177210 91177308-0d34-0410-b5e6-96231b3b80d8
