lp:~pali/llvm/llvm-3.9
- Get this branch:
- bzr branch lp:~pali/llvm/llvm-3.9
Branch merges
Import details
This branch is an import of the Subversion branch from http://llvm.org/svn/llvm-project/llvm/branches/release_39.
Last successful import was .
Recent revisions
- 135437. By tstellar
-
Merging r288433:
-------
------- ------- ------- ------- ------- ------- ------- ------- ------- --
r288433 | oranevskyy | 2016-12-01 14:58:35 -0800 (Thu, 01 Dec 2016) | 24 lines[ARM] Fix for 64-bit CAS expansion on ARM32 with -O0
Summary:
This patch fixes comparison of 64-bit atomic with its expected value in CMP_SWAP_64 expansion.Currently, the low words are compared with CMP, while the high words are compared with SBC. SBC expects the carry flag to be set if CMP detects a difference. CMP might leave the carry unset for unequal arguments though if the first one is >= than the second. This might cause the comparison logic to detect false equality.
Example of the broken C++ code:
```
std::atomic<long long> at(2);long long ll = 1;
std::atomic_compare_ exchange_ strong( &at, &ll, 3);
```
Even though the atomic `at` and the expected value `ll` are not equal and `atomic_compare_ exchange_ strong` returns `false`, `at` is changed to 3. The patch replaces SBC with CMPEQ.
Reviewers: t.p.northover
Subscribers: aemerson, rengolin, llvm-commits, asl
Differential Revision: https:/
/reviews. llvm.org/ D27315 -------
------- ------- ------- ------- ------- ------- ------- ------- ------- -- - 135436. By tstellar
-
Merging r288418:
-------
------- ------- ------- ------- ------- ------- ------- ------- ------- --
r288418 | tnorthover | 2016-12-01 13:31:59 -0800 (Thu, 01 Dec 2016) | 13 linesAArch64: fix 128-bit cmpxchg at -O0 (again, again).
This time the issue is fortunately just a simple mistake rather than a horrible
design spectre. I thought SUBS/SBCS provided sufficient NZCV flags for
comparing two 64-bit values, but they don't.The fix is slightly clunkier in AArch64 because we can't use conditional
execution to emit a pair of CMPs. Traditionally an "icmp ne i128" would map to
an EOR/EOR/ORR/CBNZ, but that uses more registers so it's easier to go with a
CSET/CINC/CBNZ combination. Slightly less efficient, but this is -O0 anyway.Thanks to Anton Korobeynikov for pointing out the issue.
-------
------- ------- ------- ------- ------- ------- ------- ------- ------- -- - 135435. By tstellar
-
Merging r277755:
-------
------- ------- ------- ------- ------- ------- ------- ------- ------- --
r277755 | tnorthover | 2016-08-04 12:32:28 -0700 (Thu, 04 Aug 2016) | 5 linesAArch64: don't assume all i128s are BUILD_PAIRs
It leads to a crash when they're not. I'm *sure* I've made this mistake before,
at least once.-------
------- ------- ------- ------- ------- ------- ------- ------- ------- -- - 135434. By tstellar
-
Revert "Merging r278268:"
This reverts commit r288454. This was committed accidently.
- 135433. By tstellar
-
Merging r287360:
-------
------- ------- ------- ------- ------- ------- ------- ------- ------- --
r287360 | hans | 2016-11-18 10:27:31 -0800 (Fri, 18 Nov 2016) | 2 linesFix test from r287353: don't use /dev/null
-------
------- ------- ------- ------- ------- ------- ------- ------- ------- -- - 135432. By tstellar
-
Merging r278268:
-------
------- ------- ------- ------- ------- ------- ------- ------- ------- --
r278268 | nhaehnle | 2016-08-10 11:51:14 -0700 (Wed, 10 Aug 2016) | 28 linesLiveIntervalAna
lysis: fix a crash in repairOldRegInRange Summary:
See the new test case for one that was (non-deterministically) crashing
on trunk and deterministically hit the assertion that I added in D23302.
Basically, the machine function contains a sequenceDS_WRITE_B32 %vreg4, %vreg14:sub0, ...
DS_WRITE_B32 %vreg4, %vreg14:sub0, ...
%vreg14:sub1<def> = COPY %vreg14:sub0 and SILoadStoreOpti
mizer:: mergeWrite2Pair merges the two DS_WRITE_B32
instructions into one before calling repairIntervalsInRange. Now repairIntervals
InRange wants to repair %vreg14, in particular, and
ends up trying to repair %vreg14:sub1 as well, but that only becomes
active _after_ the range that is to be repaired, hence the crash due
to LR.find(...) == LR.begin() at the start of repairOldRegInRange. I believe that just skipping those subrange is fine, but again, not too
familiar with that code.Reviewers: MatzeB, kparzysz, tstellarAMD
Subscribers: llvm-commits, MatzeB
Differential Revision: https:/
/reviews. llvm.org/ D23303 -------
------- ------- ------- ------- ------- ------- ------- ------- ------- -- - 135431. By tstellar
-
Merging r287339:
-------
------- ------- ------- ------- ------- ------- ------- ------- ------- --
r287339 | nhaehnle | 2016-11-18 03:55:52 -0800 (Fri, 18 Nov 2016) | 20 linesAMDGPU: Fix legalization of MUBUF instructions in shaders
Summary:
The addr64-based legalization is incorrect for MUBUF instructions with idxen
set as well as for BUFFER_LOAD/STORE_ FORMAT_ * instructions. This affects
e.g. shaders that access buffer textures.Since we never actually need the addr64-legalization in shaders, this patch
takes the easy route and keys off the calling convention. If this ever
affects (non-OpenGL) compute, the type of legalization needs to be chosen
based on some TSFlag.Bugzilla: https:/
/bugs.freedeskt op.org/ show_bug. cgi?id= 98664 Reviewers: arsenm, tstellarAMD
Subscribers: kzhuravl, wdng, yaxunl, tony-tye, llvm-commits
Differential Revision: https:/
/reviews. llvm.org/ D26747 -------
------- ------- ------- ------- ------- ------- ------- ------- ------- -- - 135430. By tstellar
-
Merging r280589:
-------
------- ------- ------- ------- ------- ------- ------- ------- ------- --
r280589 | nhaehnle | 2016-09-03 05:26:32 -0700 (Sat, 03 Sep 2016) | 19 linesAMDGPU: Fix an interaction between WQM and polygon stippling
Summary:
This fixes a rare bug in polygon stippling with non-monolithic pixel shaders.The underlying problem is as follows: the prolog part contains the polygon
stippling sequence, i.e. a kill. The main part then enables WQM based on the
_reduced_ exec mask, effectively undoing most of the polygon stippling.Since we cannot know whether polygon stippling will be used, the main part
of a non-monolithic shader must always return to exact mode to fix this
problem.Reviewers: arsenm, tstellarAMD, mareko
Subscribers: arsenm, llvm-commits, kzhuravl
Differential Revision: https:/
/reviews. llvm.org/ D23131 -------
------- ------- ------- ------- ------- ------- ------- ------- ------- -- - 135429. By tstellar
-
Merging r277504:
-------
------- ------- ------- ------- ------- ------- ------- ------- ------- --
r277504 | nhaehnle | 2016-08-02 12:31:14 -0700 (Tue, 02 Aug 2016) | 21 linesAMDGPU: Stay in WQM for non-intrinsic stores
Summary:
Two types of stores are possible in pixel shaders: stores to memory that are
explicitly requested at the API level, and stores that are an implementation
detail of register spilling or lowering of arrays.For the first kind of store, we must ensure that helper pixels have no effect
and hence WQM must be disabled. The second kind of store must always be
executed, because the written value may be loaded again in a way that is
relevant for helper pixels as well -- and there are no externally visible
effects anyway.This is a candidate for the 3.9 release branch.
Reviewers: arsenm, tstellarAMD, mareko
Subscribers: arsenm, kzhuravl, llvm-commits
Differential Revision: https:/
/reviews. llvm.org/ D22675 -------
------- ------- ------- ------- ------- ------- ------- ------- ------- -- - 135428. By tstellar
-
Merging r277500:
-------
------- ------- ------- ------- ------- ------- ------- ------- ------- --
r277500 | nhaehnle | 2016-08-02 12:17:37 -0700 (Tue, 02 Aug 2016) | 18 linesAMDGPU: Track physical registers in SIWholeQuadMode
Summary:
There are cases where uniform branch conditions are computed in VGPRs, and
we didn't correctly mark those as WQM.The stray change in basic-branch.ll is because invoking the LiveIntervals
analysis leads to the detection of a dead register that would otherwise
not be seen at -O0.This is a candidate for the 3.9 branch, as it fixes a possible hang.
Reviewers: arsenm, tstellarAMD, mareko
Subscribers: arsenm, llvm-commits, kzhuravl
Differential Revision: https:/
/reviews. llvm.org/ D22673 -------
------- ------- ------- ------- ------- ------- ------- ------- ------- --
Branch metadata
- Branch format:
- Branch format 7
- Repository format:
- Bazaar repository format 2a (needs bzr 1.16 or later)