------------------------------------------------------------------------
r247435 | david.majnemer | 2015-09-11 13:34:34 -0400 (Fri, 11 Sep 2015) | 8 lines
[X86] Make sure startproc/endproc are paired
We used different conditions to determine if we should emit startproc vs
endproc. Use the same condition to ensure that they will always be
paired.
This fixes PR24374.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@253742 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r245588 | aprantl | 2015-08-20 14:23:56 -0400 (Thu, 20 Aug 2015) | 11 lines
Fix a debug location handling bug in GVN.
Caught by the famous "DebugLoc describes the currect SubProgram" assertion.
When GVN is removing a nonlocal load it updates the debug location of the
SSA value it replaced the load with with the one of the load. In the
testcase this actually overwrites a valid debug location with an empty one.
In reality GVN has to make an arbitrary choice between two equally valid
debug locations. This patch changes to behavior to only update the
location if the value doesn't already have a debug location.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@253571 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r248858 | marek.olsak | 2015-09-29 19:37:32 -0400 (Tue, 29 Sep 2015) | 9 lines
AMDGPU/SI: Don't set DATA_FORMAT if ADD_TID_ENABLE is set
to prevent setting a huge stride, because DATA_FORMAT has a different
meaning if ADD_TID_ENABLE is set.
This is a candidate for stable llvm 3.7.
Tested-and-Reviewed-by: Christian König <christian.koenig@amd.com>
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@253236 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r246051 | Matthew.Arsenault | 2015-08-26 14:54:50 -0400 (Wed, 26 Aug 2015) | 6 lines
AMDGPU: Make sure to reserve super registers
I think this could potentially have broken if
one of the super registers were allocated
that contain v254/v255.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@253235 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r243661 | Matthew.Arsenault | 2015-07-30 13:03:11 -0400 (Thu, 30 Jul 2015) | 6 lines
AMDGPU: Set SubRegIndex size and offset
I'm not sure what reasons the comment here could have
had for not setting these. Without these set, there is
an assertion hit during DWARF emission.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@253230 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r243660 | Matthew.Arsenault | 2015-07-30 13:03:08 -0400 (Thu, 30 Jul 2015) | 9 lines
AMDGPU: Fix unreachable when emitting binary debug info
Copy implementation of applyFixup from AArch64 with AArch64 bits
ripped out.
Tests will be included with a later commit. Several other
problems must be fixed before binary debug info emission
will work.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@253229 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r243462 | Matthew.Arsenault | 2015-07-28 14:47:00 -0400 (Tue, 28 Jul 2015) | 5 lines
AMDGPU: Don't try to use LDS/vector for private if pointer value stored
If the pointer is the store's value operand, this would produce
a broken module. Make sure the use is actually for the pointer operand.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@253228 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r243461 | Matthew.Arsenault | 2015-07-28 14:29:14 -0400 (Tue, 28 Jul 2015) | 5 lines
AMDGPU: Fix crash if called function is a bitcast
getCalledFunction() is null, so this would crash. Replace
crash with an error on unsupported call.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@253227 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r251582 | hfinkel | 2015-10-28 19:43:00 -0400 (Wed, 28 Oct 2015) | 11 lines
[PowerPC] Recurse through constants when looking for TLS globals
We cannot form ctr-based loops around function calls, including calls to
__tls_get_addr used for PIC TLS variables. References to such TLS variables,
however, might be buried within constant expressions, and so we need to search
the entire constant expression to be sure that no references to such TLS
variables exist.
Fixes PR25256, reported by Eric Schweitz. This is a slightly-modified version
of the patch suggested by Eric in the bug report, and a test case I created.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@253120 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r246694 | benny.kra | 2015-09-02 15:52:23 -0400 (Wed, 02 Sep 2015) | 44 lines
[RemoveDuplicatePHINodes] Start over after removing a PHI.
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/branches/release_37@252938 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r243956 | hfinkel | 2015-08-04 02:29:12 -0400 (Tue, 04 Aug 2015) | 10 lines
[SDAG] Fix a result chain in ExpandUnalignedLoad
On the code path in ExpandUnalignedLoad which expands an unaligned vector/fp
value in terms of a legal integer load of the same size, the ChainResult needs
to be the chain result of the integer load.
No in-tree test case is currently available.
Patch by Jan Hranac!
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@252937 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r245862 | wschmidt | 2015-08-24 15:27:27 -0400 (Mon, 24 Aug 2015) | 8 lines
[PPC64LE] Fix PR24546 - Swap optimization and debug values
This patch fixes PR24546, which demonstrates a segfault during the VSX
swap removal pass. The problem is that debug value instructions were
not excluded from the list of instructions to be analyzed for webs of
related computation. I've added the test case from the PR as a crash
test in test/CodeGen/PowerPC.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@252850 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r249854 | kfischer | 2015-10-09 13:24:54 -0400 (Fri, 09 Oct 2015) | 11 lines
Clear SectionSymbols in MCContext::Reset
This was just forgotten when SectionSymbols was introduced and could cause
corruption if the MCContext was reused after Reset.
Reviewers: rafael
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13547
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@252802 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r247461 | Yunzhong_Gao | 2015-09-11 16:01:53 -0400 (Fri, 11 Sep 2015) | 4 lines
Add a non-exiting diagnostic handler for LTO.
This is in order to give LTO clients a chance to do some clean-up before
terminating the process.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@252774 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r247083 | echristo | 2015-09-08 18:14:58 -0400 (Tue, 08 Sep 2015) | 3 lines
Fix the PPC CTR Loop pass to look for calls to the intrinsics that
read CTR and count them as reading the CTR.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@252511 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r245820 | mehdi.amini | 2015-08-23 18:15:49 -0400 (Sun, 23 Aug 2015) | 64 lines
Require Dominator Tree For SROA, improve compile-time
TL-DR: SROA is followed by EarlyCSE which requires the DominatorTree.
There is no reason not to require it up-front for SROA.
Some history is necessary to understand why we ended-up here.
r123437 switched the second (Legacy)SROA in the optimizer pipeline to
use SSAUpdater in order to avoid recomputing the costly
DominanceFrontier. The purpose was to speed-up the compile-time.
Later r123609 removed the need for the DominanceFrontier in
(Legacy)SROA.
Right after, some cleanup was made in r123724 to remove any reference
to the DominanceFrontier. SROA existed in two flavors: SROA_SSAUp and
SROA_DT (the latter replacing SROA_DF).
The second argument of `createScalarReplAggregatesPass` was renamed
from `UseDomFrontier` to `UseDomTree`.
I believe this is were a mistake was made. The pipeline was not
updated and the call site was still:
PM->add(createScalarReplAggregatesPass(-1, false));
At that time, SROA was immediately followed in the pipeline by
EarlyCSE which required alread the DominatorTree. Not requiring
the DominatorTree in SROA didn't save anything, but unfortunately
it was lost at this point.
When the new SROA Pass was introduced in r163965, I believe the goal
was to have an exact replacement of the existing SROA, this bug
slipped through.
You can see currently:
$ echo "" | clang -x c++ -O3 -c - -mllvm -debug-pass=Structure
...
...
FunctionPass Manager
SROA
Dominator Tree Construction
Early CSE
After this patch:
$ echo "" | clang -x c++ -O3 -c - -mllvm -debug-pass=Structure
...
...
FunctionPass Manager
Dominator Tree Construction
SROA
Early CSE
This improves the compile time from 88s to 23s for PR17855.
https://llvm.org/bugs/show_bug.cgi?id=17855
And from 113s to 12s for PR16756
https://llvm.org/bugs/show_bug.cgi?id=16756
Reviewers: chandlerc
Differential Revision: http://reviews.llvm.org/D12267
From: Mehdi Amini <mehdi.amini@apple.com>
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@252510 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r250085 | Andrea_DiBiagio | 2015-10-12 15:22:30 -0400 (Mon, 12 Oct 2015) | 60 lines
[x86] Fix wrong lowering of vsetcc nodes (PR25080).
Function LowerVSETCC (in X86ISelLowering.cpp) worked under the wrong
assumption that for non-AVX512 targets, the source type and destination type
of a type-legalized setcc node were always the same type.
This assumption was unfortunately incorrect; the type legalizer is not always
able to promote the return type of a setcc to the same type as the first
operand of a setcc.
In the case of a vsetcc node, the legalizer firstly checks if the first input
operand has a legal type. If so, then it promotes the return type of the vsetcc
to that same type. Otherwise, the return type is promoted to the 'next legal
type', which, for vectors of MVT::i1 is always a 128-bit integer vector type.
Example (-mattr=+avx):
%0 = trunc <8 x i32> %a to <8 x i23>
%1 = icmp eq <8 x i23> %0, zeroinitializer
The initial selection dag for the code above is:
v8i1 = setcc t5, t7, seteq:ch
t5: v8i23 = truncate t2
t2: v8i32,ch = CopyFromReg t0, Register:v8i32 %vreg1
t7: v8i32 = build_vector of all zeroes.
The type legalizer would firstly check if 't5' has a legal type. If so, then it
would reuse that same type to promote the return type of the setcc node.
Unfortunately 't5' is of illegal type v8i23, and therefore it cannot be used to
promote the return type of the setcc node. Consequently, the setcc return type
is promoted to v8i16. Later on, 't5' is promoted to v8i32 thus leading to the
following dag node:
v8i16 = setcc t32, t25, seteq:ch
where t32 and t25 are now values of type v8i32.
Before this patch, function LowerVSETCC would have wrongly expanded the setcc
to a single X86ISD::PCMPEQ. Surprisingly, ISel was still able to match an
instruction. In our case, ISel would have matched a VPCMPEQWrr:
t37: v8i16 = X86ISD::VPCMPEQWrr t36, t25
However, t36 and t25 are both VR256, while the result type is instead of class
VR128. This inconsistency ended up causing the insertion of COPY instructions
like this:
%vreg7<def> = COPY %vreg3; VR128:%vreg7 VR256:%vreg3
Which is an invalid full copy (not a sub register copy).
Eventually, the backend would have hit an UNREACHABLE "Cannot emit physreg copy
instruction" in the attempt to expand the malformed pseudo COPY instructions.
This patch fixes the problem adding the missing logic in LowerVSETCC to handle
the corner case of a setcc with 128-bit return type and 256-bit operand type.
This problem was originally reported by Dimitry as PR25080. It has been latent
for a very long time. I have added the minimal reproducible from that bugzilla
as test setcc-lowering.ll.
Differential Revision: http://reviews.llvm.org/D13660
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@252484 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r250324 | wschmidt | 2015-10-14 16:45:00 -0400 (Wed, 14 Oct 2015) | 10 lines
[PowerPC] Fix invalid lxvdsx optimization (PR25157)
PR25157 identifies a bug where a load plus a vector shuffle is
incorrectly converted into an LXVDSX instruction. That optimization
is only valid if the load is of a doubleword, and in the noted case,
it was not. This corrects that problem.
Joint patch with Eric Schweitz, who provided the bugpoint-reduced test
case.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@252483 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r247757 | geek4civic | 2015-09-15 20:10:43 -0400 (Tue, 15 Sep 2015) | 9 lines
llvm/CodeGen/CommandFlags.h: Prune doubleslash in #include.
While packaging 3.7 for Fedora, the debug info splitting
process fell over this, so fix it upstream seems like a good plan.
This should be put in the 3.7 branch as well.
Noticed by Dave Airlie <airlied@redhat.com>
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@252482 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r246937 | hfinkel | 2015-09-06 00:17:30 -0400 (Sun, 06 Sep 2015) | 13 lines
[PowerPC] Don't commute trivial rlwimi instructions
To commute a trivial rlwimi instructions (meaning one with a full mask and zero
shift), we'd need to ability to form an all-zero mask (instead of an all-one
mask) using rlwimi. We can't represent this, however, and we'll miscompile code
if we try.
The code quality problem that this highlights (that SDAG simplification can
lead to us generating an ISD::OR node with a constant zero LHS) will be fixed
as a follow-up.
Fixes PR24719.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@252481 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r246900 | hfinkel | 2015-09-04 20:02:59 -0400 (Fri, 04 Sep 2015) | 14 lines
[PowerPC] Fix and(or(x, c1), c2) -> rlwimi generation
PPCISelDAGToDAG has a transformation that generates a rlwimi instruction from
an input pattern that looks like this:
and(or(x, c1), c2)
but the associated logic does not work if there are bits that are 1 in c1 but 0
in c2 (these are normally canonicalized away, but that can't happen if the 'or'
has other users. Make sure we abort the transformation if such bits are
discovered.
Fixes PR24704.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@252480 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r246675 | hfinkel | 2015-09-02 12:52:37 -0400 (Wed, 02 Sep 2015) | 9 lines
[PowerPC] Don't always consider P8Altivec-only masks in LowerVECTOR_SHUFFLE
LowerVECTOR_SHUFFLE needs to decide whether to pass a vector shuffle off to the
TableGen-generated matching code, and it does this by testing the same
predicates used by the TableGen files. Unfortunately, when we added new
P8Altivec-only predicates, we started universally testing them in
LowerVECTOR_SHUFFLE, and if then matched when targeting a system prior to a P8,
we'd end up with a selection failure.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@252479 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r246400 | hfinkel | 2015-08-30 18:12:50 -0400 (Sun, 30 Aug 2015) | 20 lines
[PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands
There were really two problems here. The first was that we had the truth tables
for signed i1 comparisons backward. I imagine these are not very common, but if
you have:
setcc i1 x, y, LT
this has the '0 1' and the '1 0' results flipped compared to:
setcc i1 x, y, ULT
because, in the signed case, '1 0' is really '-1 0', and the answer is not the
same as in the unsigned case.
The second problem was that we did not have patterns (at all) for the unsigned
comparisons select_cc nodes for i1 comparison operands. This was the specific
cause of PR24552. These had to be added (and a missing Altivec promotion added
as well) to make sure these function for all types. I've added a bunch more
test cases for these patterns, and there are a few FIXMEs in the test case
regarding code-quality.
Fixes PR24552.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@252478 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r246372 | hfinkel | 2015-08-30 03:44:05 -0400 (Sun, 30 Aug 2015) | 10 lines
[PowerPC] Don't assume ADDISdtprelHA's source is r3
Even through ADDISdtprelHA generally has r3 as its source register, it is
possible for the instruction scheduler to move things around such that some
other register is the source. We need to print the actual source register, not
always r3. Fixes PR24394.
The test case will come in a follow-up commit because it depends on MIR
target-flags parsing.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@252477 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r245907 | hfinkel | 2015-08-24 19:48:28 -0400 (Mon, 24 Aug 2015) | 6 lines
[PowerPC] PPCVSXFMAMutate should ignore trivial-copy addends
We might end up with a trivial copy as the addend, and if so, we should ignore
the corresponding FMA instruction. The trivial copy can be coalesced away later,
so there's nothing to do here. We should not, however, assert. Fixes PR24544.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@252476 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r251622 | vkalintiris | 2015-10-29 10:17:16 +0000 (Thu, 29 Oct 2015) | 17 lines
[mips] Check the register class before replacing materializations of zero with $zero in microMIPS.
Summary:
The microMIPS register class GPRMM16 does not contain the $zero register.
However, MipsSEDAGToDAGISel::replaceUsesWithZeroReg() would replace uses
of the $dst register:
[d]addiu, $dst, $zero, 0
with the $zero register, without checking for membership in the register
class of the target machine operand.
Reviewers: dsanders
Subscribers: llvm-commits, dsanders
Differential Revision: http://reviews.llvm.org/D13984
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@252158 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r245741 | hfinkel | 2015-08-21 17:34:24 -0400 (Fri, 21 Aug 2015) | 8 lines
[PowerPC] PPCVSXFMAMutate should not segfault on undef input registers
When PPCVSXFMAMutate would look at the input addend register, it would get its
input value number. This would fail, however, if the register was undef,
causing a segfault. Don't segfault (just skip such FMA instructions).
Fixes the test case from PR24542 (although that may have been over-reduced).
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@252132 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r249718 | ast | 2015-10-08 11:52:40 -0700 (Thu, 08 Oct 2015) | 16 lines
[bpf] Do not expand UNDEF SDNode during insn selection lowering
o Before this patch, BPF backend will expand UNDEF node
to i64 constant 0.
o For second pass of dag combiner, legalizer will run through
each to-be-processed dag node.
o If any new SDNode is generated and has an undef operand,
dag combiner will put undef node, newly-generated constant-0 node,
and any node which uses these nodes in the working list.
o During this process, it is possible undef operand is
generated again, and this will form an infinite loop
for dag combiner pass2.
o This patch allows UNDEF to be a legal type.
Signed-off-by: Yonghong Song <yhs@plumgrid.com>
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@251177 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r249371 | ast | 2015-10-05 21:00:53 -0700 (Mon, 05 Oct 2015) | 25 lines
[bpf] Avoid extra pointer arithmetic for stack access
For the program like below
struct key_t {
int pid;
char name[16];
};
extern void test1(char *);
int test() {
struct key_t key = {};
test1(key.name);
return 0;
}
For key.name, the llc/bpf may generate the below code:
R1 = R10 // R10 is the frame pointer
R1 += -24 // framepointer adjustment
R1 |= 4 // R1 is then used as the first parameter of test1
OR operation is not recognized by in-kernel verifier.
This patch introduces an intermediate FI_ri instruction and
generates the following code that can be properly verified:
R1 = R10
R1 += -20
Patch by Yonghong Song <yhs@plumgrid.com>
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@251175 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r247128 | dsanders | 2015-09-09 10:53:20 +0100 (Wed, 09 Sep 2015) | 31 lines
Fix vector splitting for extract_vector_elt and vector elements of <8-bits.
Summary:
One of the vector splitting paths for extract_vector_elt tries to lower:
define i1 @via_stack_bug(i8 signext %idx) {
%1 = extractelement <2 x i1> <i1 false, i1 true>, i8 %idx
ret i1 %1
}
to:
define i1 @via_stack_bug(i8 signext %idx) {
%base = alloca <2 x i1>
store <2 x i1> <i1 false, i1 true>, <2 x i1>* %base
%2 = getelementptr <2 x i1>, <2 x i1>* %base, i32 %idx
%3 = load i1, i1* %2
ret i1 %3
}
However, the elements of <2 x i1> are not byte-addressible. The result of this
is that the getelementptr expands to '%base + %idx * (1 / 8)' which simplifies
to '%base + %idx * 0', and then simply '%base' causing all values of %idx to
extract element zero.
This commit fixes this by promoting the vector elements of <8-bits to i8 before
splitting the vector.
This fixes a number of test failures in pocl.
Reviewers: pekka.jaaskelainen
Subscribers: pekka.jaaskelainen, llvm-commits
Differential Revision: http://reviews.llvm.org/D12591
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@247539 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r247372 | dexonsmith | 2015-09-10 18:34:59 -0700 (Thu, 10 Sep 2015) | 15 lines
AsmWriter: Avoid O(N^2) processing of metadata
Fix embarrassing bugs I introduced to the `SlotTracker` in or around
r235785. I had us iterating through every instruction in a function
(and hitting a map in the LLVMContext) for every basic block in the
function.
While there, completely avoid the call to
`SlotTracker::processFunctionMetadata()` from
`SlotTracker::processFunction()` if we've speculatively done this
already in `SlotTracker::processModule()` by checking
`ShouldInitializeAllMetadata` (this wasn't an algorithmic problem, but
it's touching the same line of code).
Fixes PR24699.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@247440 91177308-0d34-0410-b5e6-96231b3b80d8
It restores the signature of LLVMBuildLandingPad in the C API back to what it
was in 3.6 and earlier.
The 3.7.0 release should have had this but it did not.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@247191 91177308-0d34-0410-b5e6-96231b3b80d8
Tom Stellard