------------------------------------------------------------------------
r227822 | thomas.stellard | 2015-02-02 13:02:28 -0500 (Mon, 02 Feb 2015) | 6 lines
R600/SI: 64-bit and larger memory access must be at least 4-byte aligned
This is true for SI only. CI+ supports unaligned memory accesses,
but this requires driver support, so for now we disallow unaligned
accesses for all GCN targets.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@235206 91177308-0d34-0410-b5e6-96231b3b80d8
Original message from r231227:
Fix PR22408 - LLVM producing AArch64 TLS relocations that GNU linkers cannot handle yet.
As is described at http://llvm.org/bugs/show_bug.cgi?id=22408, the GNU linkers
ld.bfd and ld.gold currently only support a subset of the whole range of AArch64
ELF TLS relocations. Furthermore, they assume that some of the code sequences to
access thread-local variables are produced in a very specific sequence.
When the sequence is not as the linker expects, it can silently mis-relaxe/mis-optimize
the instructions.
Even if that wouldn't be the case, it's good to produce the exact sequence,
as that ensures that linkers can perform optimizing relaxations.
This patch:
* implements support for 16MiB TLS area size instead of 4GiB TLS area size. Ideally clang
would grow an -mtls-size option to allow support for both, but that's not part of this patch.
* by default doesn't produce local dynamic access patterns, as even modern ld.bfd and ld.gold
linkers do not support the associated relocations. An option (-aarch64-elf-ldtls-generation)
is added to enable generation of local dynamic code sequence, but is off by default.
* makes sure that the exact expected code sequence for local dynamic and general dynamic
accesses is produced, by making use of a new pseudo instruction. The patch also removes
two (AArch64ISD::TLSDESC_BLR, AArch64ISD::TLSDESC_CALL) pre-existing AArch64-specific pseudo
SDNode instructions that are superseded by the new one (TLSDESC_CALLSEQ).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@234393 91177308-0d34-0410-b5e6-96231b3b80d8
Original message from r233351:
Fix a bug in SelectionDAG scheduling backtracking code: PR22304.
It can happen (by line CurSU->isPending = true; // This SU is not in
AvailableQueue right now.) that a SUnit is mark as available but is
not in the AvailableQueue. For SUnit being selected for scheduling
both conditions must be met.
This patch mainly defensively protects from invalid removing a node
from a queue. Sometimes nodes are marked isAvailable but are not in
the queue because they have been defered due to some hazard.
The other two commits move a test from CodeGen/Generic to Codegen/X86.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@234303 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r233153 | probinson | 2015-03-24 17:10:24 -0700 (Tue, 24 Mar 2015) | 7 lines
'optnone' should not disable DAG combiner.
Reverts the code change from r221168 and the relevant test.
It was a mistake to disable the combiner, and based on the ultimate
definition of 'optnone' we shouldn't have considered the test case
as failing in the first place.
------------------------------------------------------------------------
r233584 | probinson | 2015-03-30 12:37:44 -0700 (Mon, 30 Mar 2015) | 9 lines
Verify 'optnone' can run DAG combiner when appropriate.
Adds a test to verify the behavior that r233153 restored: 'optnone'
does not spuriously disable the DAG combiner, and in fact there are
cases where the DAG combiner must run (even at -O0 or 'optnone') in
order for codegen to succeed.
Differential Revision: http://reviews.llvm.org/D8614
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@233871 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r227214 | marek.olsak | 2015-01-27 12:27:15 -0500 (Tue, 27 Jan 2015) | 2
lines
R600/SI: Enable all tests that pass on VI without changes
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@233734 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r227212 | marek.olsak | 2015-01-27 12:25:11 -0500 (Tue, 27 Jan 2015) | 9 lines
R600/SI: Don't set patterns for chip-specific instructions while having pseudos
Only pseudos have patterns on them.
Also don't set the asm string for VINTRP_Pseudo. All pseudos should have empty
asm.
This matches what all other multiclasses do.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@233732 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r227211 | marek.olsak | 2015-01-27 12:25:07 -0500 (Tue, 27 Jan 2015) | 5 lines
R600/SI: Add VI versions of LDS atomics
Each class is split into two: one adds let statements around non-pseudos,
and the other one specifies the parameters.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@233731 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r227209 | marek.olsak | 2015-01-27 12:24:58 -0500 (Tue, 27 Jan 2015) | 4 lines
R600/SI: Add VI versions of MUBUF loads and stores
This enables a lot of existing patterns for VI.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@233729 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r227208 | marek.olsak | 2015-01-27 12:24:54 -0500 (Tue, 27 Jan 2015) | 7 lines
R600/SI: Add pseudos for MUBUF loads and stores
This defines the SI versions only, so it shouldn't change anything.
There are no changes other than using the new multiclasses, adding missing
mayLoad/mayStore, and formatting fixes.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@233728 91177308-0d34-0410-b5e6-96231b3b80d8
Original message:
[DAGCombine] Fix a bug in a BUILD_VECTOR combine
When trying to convert a BUILD_VECTOR into a shuffle, we try to split a single source vector that is twice as wide as the destination vector.
We can not do this when we also need the zero vector to create a blend.
This fixes PR22774.
Differential Revision: http://reviews.llvm.org/D8040
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@232807 91177308-0d34-0410-b5e6-96231b3b80d8
Original message:
[X86] Fix wrong target specific combine on SETCC nodes.
Part of the folding logic implemented by function 'PerformISDSETCCCombine'
only worked under the assumption that the condition code in input could have
been either SETNE or SETEQ.
Unfortunately that assumption was incorrect, and in some cases the algorithm
ended up incorrectly folding SETCC nodes.
The incorrect folding only affected SETCC dag nodes where:
- one of the operands was a build_vector of all zeroes;
- the other operand was a SIGN_EXTEND from a vector of MVT:i1 elements;
- the condition code was neither SETNE nor SETEQ.
Example:
(setcc (v4i32 (sign_extend v4i1:%A)), (v4i32 VectorOfAllZeroes), setge)
Before this patch, the entire dag node sequence from the example was
incorrectly folded to node %A.
With this patch, the dag node sequence is folded to a
(xor %A, (v4i1 VectorOfAllOnes)).
Added test setcc-combine.ll.
Thanks to Greg Bedwell for spotting this issue.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@232804 91177308-0d34-0410-b5e6-96231b3b80d8
Original commit message:
[X86][AVX] Fix wrong lowering of VPERM2X128 nodes
There were cases where the backend computed a wrong permute mask for a VPERM2X128 node.
Example:
\code
define <8 x float> @foo(<8 x float> %a, <8 x float> %b) {
%shuffle = shufflevector <8 x float> %a, <8 x float> %b, <8 x i32> <i32 undef, i32 undef, i32 6, i32 7, i32 undef, i32 undef, i32 6, i32 7>
ret <8 x float> %shuffle
}
\code end
Before this patch, llc (with -mattr=+avx) emitted the following vperm2f128:
vperm2f128 $0, %ymm0, %ymm0, %ymm0 # ymm0 = ymm0[0,1,0,1]
With this patch, llc emits a vperm2f128 with a correct permute mask:
vperm2f128 $17, %ymm0, %ymm0, %ymm0 # ymm0 = ymm0[2,3,2,3]
Differential Revision: http://reviews.llvm.org/D8119
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@232803 91177308-0d34-0410-b5e6-96231b3b80d8
Original commit message:
[X86][AVX] Fix wrong lowering of v4x64 shuffles into concat_vector plus extract_subvector nodes.
This patch fixes a bug in the shuffle lowering logic implemented by function
'lowerV2X128VectorShuffle'.
The are few cases where function 'lowerV2X128VectorShuffle' wrongly expands a
shuffle of two v4X64 vectors into a CONCAT_VECTORS of two EXTRACT_SUBVECTOR
nodes. The problematic expansion only occurs when the shuffle mask M has an
'undef' element at position 2, and M is equivalent to mask <0,1,4,5>.
In that case, the algorithm propagates the wrong vector to one of the two
new EXTRACT_SUBVECTOR nodes.
Example:
;;
define <4 x double> @test(<4 x double> %A, <4 x double> %B) {
entry:
%0 = shufflevector <4 x double> %A, <4 x double> %B, <4 x i32><i32 undef, i32 1, i32 undef, i32 5>
ret <4 x double> %0
}
;;
Before this patch, llc (-mattr=+avx) generated:
vinsertf128 $1, %xmm0, %ymm0, %ymm0
With this patch, llc correctly generates:
vinsertf128 $1, %xmm1, %ymm0, %ymm0
Added test lower-vec-shuffle-bug.ll
Differential Revision: http://reviews.llvm.org/D8259
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@232753 91177308-0d34-0410-b5e6-96231b3b80d8
Original commit message:
Summary:
ScalarEvolutionExpander assumes that the header block of a loop is a
legal place to have a use for a phi node. This is true only for phis
that are either in the header or dominate the header block, but it is
not true for phi nodes that are strictly internal to the loop body.
This change teaches ScalarEvolutionExpander to place uses of PHI nodes
in the basic block the PHI nodes belong to. This is always legal, and
`hoistIVInc` ensures that the said position dominates `IsomorphicInc`.
Reviewers: atrick
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8311
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@232416 91177308-0d34-0410-b5e6-96231b3b80d8
Original commit message:
[X86] Fix a regression introduced by r223641.
The permps and permd instructions have their operands swapped compared to the
intrinsic definition. Therefore, they do not fall into the INTR_TYPE_2OP
category.
I did not create a new category for those two, as they are the only one AFAICT
in that case.
<rdar://problem/20108262>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@232118 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r227089 | vkalintiris | 2015-01-26 13:33:22 +0100 (Mon, 26 Jan 2015) | 15 lines
[mips] Enable arithmetic and binary operations for the i128 data type.
Summary:
This patch adds support for some operations that were missing from
128-bit integer types (add/sub/mul/sdiv/udiv... etc.). With these
changes we can support the __int128_t and __uint128_t data types
from C/C++.
Depends on D7125
Reviewers: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7143
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@231860 91177308-0d34-0410-b5e6-96231b3b80d8
[DAGCombiner] Fix wrong folding of AND dag nodes.
This patch fixes the logic in the DAGCombiner that folds an AND node according
to rule: (and (X (load V)), C) -> (X (load V))
An AND between a vector load 'X' and a constant build_vector 'C' can be folded
into the load itself only if we can prove that the AND operation is redundant.
The algorithm implemented by 'visitAND' firstly computes the splat value 'S'
from C, and then checks if S has the lower 'B' bits set (where B is the size in
bits of the vector element type). The algorithm takes into account also the
'undef' bits in the splat mask.
Unfortunately, the algorithm only worked under the assumption that the size of S
is a multiple of the vector element type. With this patch, we conservatively
avoid folding the AND if the splat bits are not compatible with the vector
element type.
Added X86 test and-load-fold.ll
Differential Revision: http://reviews.llvm.org/D8085
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@231702 91177308-0d34-0410-b5e6-96231b3b80d8
LoopRotate: When reconstructing loop simplify form don't split edges
from indirectbrs.
Yet another chapter in the endless story. While this looks like we leave
the loop in a non-canonical state this replicates the logic in
LoopSimplify so it doesn't diverge from the canonical form in any way.
PR21968
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@231698 91177308-0d34-0410-b5e6-96231b3b80d8
MC: Allow multiple comma-separated expressions on the .uleb128
directive.
For compatiblity with GNU as. Binutils documents this as
'.uleb128 expressions'. Subtle, isn't it?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@231675 91177308-0d34-0410-b5e6-96231b3b80d8
Filip Pizlo pointed out that this changes the C API.
It's too late in the release process to figure out how we want to
handle this. Reverting the patch is essentially a way of buying time:
we don't change the API at the source level for now, we're not
trying to fix it with a last-minute patch with a risk of unintended
effects, and we preserve our options for fixing this in 3.6.1.
This is not ideal, but I think it's the best compromise at this stage.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@230431 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r229731 | sanjoy | 2015-02-18 11:32:25 -0800 (Wed, 18 Feb 2015) | 10 lines
Partial fix for bug 22589
Don't spend the entire iteration space in the scalar loop prologue if
computing the trip count overflows. This change also gets rid of the
backedge check in the prologue loop and the extra check for
overflowing trip-count.
Differential Revision: http://reviews.llvm.org/D7715
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@229757 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r229352 | majnemer | 2015-02-15 20:02:09 -0800 (Sun, 15 Feb 2015) | 8 lines
IR: Properly return nullptr when getAggregateElement is out-of-bounds
We didn't properly handle the out-of-bounds case for
ConstantAggregateZero and UndefValue. This would manifest as a crash
when the constant folder was asked to fold a load of a constant global
whose struct type has no operands.
This fixes PR22595.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@229588 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r229529 | rnk | 2015-02-17 12:02:34 -0800 (Tue, 17 Feb 2015) | 8 lines
Expose LLVM_VERSION_PATCH in llvm-config.h
There was no reason to keep this private in config.h, and users
requested that it be available in PR22615.
Also fix a bug where patch versions of '0' would cause the macro to
remain undefined. The "#cmakedefine" command only creates a macro if the
named variable would be considered true in the context of an if().
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@229567 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r229495 | delena | 2015-02-17 05:10:05 -0800 (Tue, 17 Feb 2015) | 8 lines
Fixed a bug in store sinking.
The problem was in store-sink barrier check.
Store sink barrier should be checked for ModRef (read-write) mode.
http://llvm.org/bugs/show_bug.cgi?id=22613
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@229564 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r226808 | delena | 2015-01-22 04:07:59 -0800 (Thu, 22 Jan 2015) | 10 lines
Fixed a bug in type legalizer for masked load/store intrinsics.
The problem occurs when after vectorization we have type
<2 x i32>. This type is promoted to <2 x i64> and then requires
additional efforts for expanding loads and truncating stores.
I added EXPAND / TRUNCATE attributes to the masked load/store
SDNodes. The code now contains additional shuffles.
I've prepared changes in the cost estimation for masked memory
operations, it will be submitted separately.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@229561 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r226791 | delena | 2015-01-22 00:20:06 -0800 (Thu, 22 Jan 2015) | 7 lines
Fixed a bug in masked load/store in reversed loop.
Added a test.
The bug was submitted to bugzilla:
http://llvm.org/bugs/show_bug.cgi?id=22225
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@229555 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r229421 | dexonsmith | 2015-02-16 11:18:01 -0800 (Mon, 16 Feb 2015) | 33 lines
Bitcode: Fix major regression: large files w/ debug info
The metadata/value split introduced a major regression reading large
bitcode files that contain debug info (or other cyclic (non-self
reference) metadata graphs). For the first time in a while, I dropped
from libLTO.dylib down to `llvm-lto` with a non-trivial bitcode file
(~350MB), and I hit this when reading the result of ld64's `-save-temps`
in `llvm-lto`.
Here's pseudo-code for what was going on:
read-main-metadata-block:
for each md:
if has-fwd-ref: // Only true for cyclic graphs.
any-fwd-refs <- true
if any-fwd-refs:
foreach md:
resolve-cycles(md) // Handle cycles.
foreach function:
read-function-metadata-block: // Such as !alias, !loop
if any-fwd-refs:
foreach md: // (all metadata, not just this block)
resolve-cycles(md) // A no-op, but the loop is expensive!!
This commit resets the `AnyFwdRefs` flag to `false`. This on its own
was enough to change my Release+Asserts `llvm-lto` time for reading this
bitcode from over 20 minutes (I gave up on it) to 20 seconds. I've gone
further by tracking the min/max metadata forward-references in a
metadata block. This protects against a schema that has lots of
functions that each reference their own metadata cycle.
Unfortunately, this regression is in the 3.6 branch as well.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@229545 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r229029 | chandlerc | 2015-02-12 18:30:01 -0800 (Thu, 12 Feb 2015) | 16 lines
[IC] Fix a bug with the instcombine canonicalizing of loads and
propagating of metadata.
We were propagating !nonnull metadata even when the newly formed load is
no longer of a pointer type. This is clearly broken and results in LLVM
failing the verifier and aborting. This patch just restricts the
propagation of !nonnull metadata to when we actually have a pointer
type.
This bug report and the initial version of this patch was provided by
Charles Davis! Many thanks for finding this!
We still need to add logic to round-trip the metadata correctly if we
combine from pointer types to integer types and then back by using range
metadata for the integer type loads. But this is the minimal and safe
version of the patch, which is important so we can backport it into 3.6.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@229036 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r228969 | hfinkel | 2015-02-12 14:43:52 -0800 (Thu, 12 Feb 2015) | 7 lines
[SDAG] Don't try to use FP_EXTEND/FP_ROUND for int<->fp promotions
The PowerPC backend has long promoted some floating-point vector operations
(such as select) to integer vector operations. Unfortunately, this behavior was
broken by r216555. When using FP_EXTEND/FP_ROUND for promotions, we must check
that both the old and new types are floating-point types. Otherwise, we must
use BITCAST as we did prior to r216555 for everything.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@228986 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r226616 | adrian | 2015-01-20 14:37:25 -0800 (Tue, 20 Jan 2015) | 2 lines
DebugLocs without a scope should fail the verification.
Follow-up to r226588.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@228985 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r226588 | adrian | 2015-01-20 10:03:37 -0800 (Tue, 20 Jan 2015) | 1 line
Add an assertion and prefer a crash over an infinite loop.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@228984 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r228979 | majnemer | 2015-02-12 15:26:26 -0800 (Thu, 12 Feb 2015) | 8 lines
X86: Don't crash if we can't decode the pshufb mask
Constant pool entries are uniqued by their contents regardless of their
type. This means that a pshufb can have a shuffle mask which isn't a
simple array of bytes.
The code path which attempts to decode the mask didn't check for
failure, causing PR22559.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_36@228983 91177308-0d34-0410-b5e6-96231b3b80d8
Tom Stellard
Kristof Beyls
Pawel Bylica
Paul Robinson
Andrea Di Biagio
Sanjoy Das
Quentin Colombet
Dimitry Andric
Joerg Sonnenberger
Hans Wennborg
Hal Finkel
Reid Kleckner
Peter Collingbourne
Kai Nacke
Josh Klontz