Pre-P8, when we generate code for unaligned vector loads (for Altivec and QPX
types), even when accounting for the combining that takes place for multiple
consecutive such loads, there is at least one load instructions and one
permutation for each load. Make sure the cost reported reflects the cost of the
permutes as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246807 91177308-0d34-0410-b5e6-96231b3b80d8
If you compute the MMO offset using unsigned arithmetic, you end up with a
large positive offset instead of a small negative one. In theory, this could
cause bad instruction-scheduling decisions later.
I noticed this by inspection from the debug output, and using that for the
regression test is the best I can do right now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246805 91177308-0d34-0410-b5e6-96231b3b80d8
The visit order being used in the base pointer inference algorithm is currently non-deterministic. When working on http://reviews.llvm.org/D12583, I discovered that we were relying on a peephole optimization to get deterministic ordering in one of the test cases.
This change is intented to let me test and land http://reviews.llvm.org/D12583. The current code will not be long lived. I'm starting to investigate a rewrite of the algorithm which will combine the post-process step into the initial algorithm and make the visit order determistic. Before doing that, I wanted to make sure the existing code was complete and the test were stable. Hopefully, patches should be up for review for the new algorithm this week or early next.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246801 91177308-0d34-0410-b5e6-96231b3b80d8
Splitting basic blocks really messes up WinEHPrepare. We can remove this
change when SEH uses the new EH IR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246799 91177308-0d34-0410-b5e6-96231b3b80d8
* ``the value cannot fit within the destination type`` is ambiguous.
It could mean overflow, underflow (not in the IEEE-754 sense) or a
result that cannot be exactly represented and requires rounding or it
could mean some combination of these. The semantics now state it means
overflow **only**.
* Using "truncation" in the semantics is very misleading given that it
doesn't necessarily truncate (i.e. round to zero). For example on
x86_64 with SSE2 this is currently mapped to cvtsd2ss instruction
who's rounding behaviour is dependent on the MXCSR register which
is usually set to round to nearest even by default. The semantics
now state that the rounding mode is undefined.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246792 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This fixes bugzilla bug 24656. Fixes the case where there is a forward
reference to a global variable using an ID (i.e. @0). It does this by
passing the address space of the initializer pointer for which the
forward referenced global is used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246788 91177308-0d34-0410-b5e6-96231b3b80d8
This prevents MC clients from getting COFF.h, which conflicts with
winnt.h macros. Also a minor IWYU cleanup. Now the only public headers
including COFF.h are in Object, and they actually need it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246784 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Fixes bug 24645. Problem appears to be that the type may be undefined
when ConvertValIDToValue is called.
Reviewers: kcc
Subscribers: llvm-commits
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246779 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Fixes bug 24646. Previous code was not checking if an index into a vector
was valid, resulting in a SEGV. Fixed by assuming the construct can't
be parsed when given this input.
Reformat and add test.
Differential Revision: http://reviews.llvm.org/D12539
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246774 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes bug 24646. Previous code was not checking if an index into a vector
was valid, resulting in a SEGV. Fixed by assuming the construct can't
be parsed when given this input.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246773 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This function was not taking into account that the
input type could be a vector, and wasn't properly
working for vector types.
This caused an assert when building spec2k6 perlbmk for armv8.
Reviewers: rengolin, mzolotukhin
Subscribers: silviu.baranga, mzolotukhin, rengolin, eugenis, jmolloy, aemerson, llvm-commits
Differential Revision: http://reviews.llvm.org/D12559
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246759 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This intrinsic can be used to extract a pointer to the exception caught by
a given catchpad. Its argument has token type and must be a `catchpad`.
Also clarify ExtendingLLVM documentation regarding overloaded intrinsics.
Reviewers: majnemer, andrew.w.kaylor, sanjoy, rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12533
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246752 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Add a `cleanupendpad` instruction, used to mark exceptional exits out of
cleanups (for languages/targets that can abort a cleanup with another
exception). The `cleanupendpad` instruction is similar to the `catchendpad`
instruction in that it is an EH pad which is the target of unwind edges in
the handler and which itself has an unwind edge to the next EH action.
The `cleanupendpad` instruction, similar to `cleanupret` has a `cleanuppad`
argument indicating which cleanup it exits. The unwind successors of a
`cleanuppad`'s `cleanupendpad`s must agree with each other and with its
`cleanupret`s.
Update WinEHPrepare (and docs/tests) to accomodate `cleanupendpad`.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12433
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246751 91177308-0d34-0410-b5e6-96231b3b80d8
If ld.gold is configured without --enable-thread, ld.gold might not load libpthread.so.
Preloading LLVMgold.so loads also libpthread.so.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246739 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch introduces a side table in Merge Functions to
efficiently remove functions from the function set when functions
they refer to are merged. Previously these functions would need to
be compared lg(N) times to find the appropriate FunctionNode in the
tree to defer. With the recent determinism changes, this comparison
is more expensive. In addition, the removal function would not always
actually remove the function from the set (i.e. after remove(F),
there would sometimes still be a node in the tree which contains F).
With these changes, these functions are properly deferred, and so more
functions can be merged. In addition, when there are many merged
functions (and thus more deferred functions), there is a speedup:
chromium: 48678 merged -> 49380 merged; 6.58s -> 5.49s
libxul.so: 41004 merged -> 41030 merged; 8.02s -> 6.94s
mysqld: 1607 merged -> 1607 merged (same); 0.215s -> 0.212s (probably noise)
Author: jrkoenig
Reviewers: jfb, dschuff
Subscribers: llvm-commits, nlewycky
Differential revision: http://reviews.llvm.org/D12537
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246735 91177308-0d34-0410-b5e6-96231b3b80d8
We used to accept (and even test, and generate) 16-byte alignment
for 32-byte nontemporal stores, but they require 32-byte alignment,
per SDM. Found by inspection.
Instead of hardcoding 16 in the patfrag, check for natural alignment.
Also fix the autoupgrade and the various tests.
Also, use explicit -mattr instead of -mcpu: I stared at the output
several minutes wondering why I get 2x movntps for the unaligned
case (which is the ideal output, but needs some work: see FIXME),
until I remembered corei7-avx implies +slow-unaligned-mem-32.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246733 91177308-0d34-0410-b5e6-96231b3b80d8
Function::print isn't interestingly different from Value::print. Just
let the only caller (in PrintCallGraphPass) call the Value version.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246720 91177308-0d34-0410-b5e6-96231b3b80d8
We can chain other fragments to avoid repeating conditions.
This also fixes a potential bug (that realistically can't happen),
where we would match indexed nontemporal stores for i32/i64.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246719 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a bug in change 246133. I didn't handle the case where we had a cycle in the use graph and could add an instruction we were about to erase back on to the worklist. Oddly, I have not been able to write a small test case for this, even with the AssertingVH added. I have confirmed the basic theory for the fix on a large failing example, but all attempts to reduce that to something appropriate for a test case have failed.
Differential Revision: http://reviews.llvm.org/D12575
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246718 91177308-0d34-0410-b5e6-96231b3b80d8
I'm adding a regression test to better cover code generation for unaligned
vector loads and stores, but there's no functional change to the code
generation here. There is an improvement to the cost model for unaligned vector
loads and stores, mostly for QPX (for which we were not previously accounting
for the permutation-based loads), and the cost model implementation is cleaner.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246712 91177308-0d34-0410-b5e6-96231b3b80d8
The plan is to use this for the sanitizer test suite on Windows. See
PR24554 for more details on why we need this.
Tested manually by injecting rand() into a sanitizer test and watching
what it does.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246704 91177308-0d34-0410-b5e6-96231b3b80d8
After hitting @llvm.assume(X) we can:
- propagate equality that X == true
- if X is icmp/fcmp (with eq operation), and one of operand
is constant we can change all variables with constants in the same BasicBlock
http://reviews.llvm.org/D11918
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246695 91177308-0d34-0410-b5e6-96231b3b80d8
This makes RemoveDuplicatePHINodes more effective and fixes an assertion
failure. Triggering the assertions requires a DenseSet reallocation
so this change only contains a constructive test.
I'll explain the issue with a small example. In the following function
there's a duplicate PHI, %4 and %5 are identical. When this is found
the DenseSet in RemoveDuplicatePHINodes contains %2, %3 and %4.
define void @F() {
br label %1
; <label>:1 ; preds = %1, %0
%2 = phi i32 [ 42, %0 ], [ %4, %1 ]
%3 = phi i32 [ 42, %0 ], [ %5, %1 ]
%4 = phi i32 [ 42, %0 ], [ 23, %1 ]
%5 = phi i32 [ 42, %0 ], [ 23, %1 ]
br label %1
}
after RemoveDuplicatePHINodes runs the function looks like this. %3 has
changed and is now identical to %2, but RemoveDuplicatePHINodes never
saw this.
define void @F() {
br label %1
; <label>:1 ; preds = %1, %0
%2 = phi i32 [ 42, %0 ], [ %4, %1 ]
%3 = phi i32 [ 42, %0 ], [ %4, %1 ]
%4 = phi i32 [ 42, %0 ], [ 23, %1 ]
br label %1
}
If the DenseSet does a reallocation now it will reinsert all
keys and stumble over %3 now having a different hash value than it had
when inserted into the map for the first time. This change clears the
set whenever a PHI is deleted and starts the progress from the
beginning, allowing %3 to be deleted and avoiding inconsistent DenseSet
state. This potentially has a negative performance impact because
it rescans all PHIs, but I don't think that this ever makes a difference
in practice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246694 91177308-0d34-0410-b5e6-96231b3b80d8
