(r242742 is the interesting patch here, but I picked the others too to get a clean
merge since there's been some back-and-forth on this file.)
------------------------------------------------------------------------
r242733 | matze | 2015-07-20 16:17:14 -0700 (Mon, 20 Jul 2015) | 3 lines
Revert "ARM: Use SpecificBumpPtrAllocator to fix leak introduced in r241920"
This reverts commit r241951. It caused http://llvm.org/PR24190
------------------------------------------------------------------------
------------------------------------------------------------------------
r242734 | matze | 2015-07-20 16:17:16 -0700 (Mon, 20 Jul 2015) | 3 lines
Revert "ARMLoadStoreOpt: Merge subs/adds into LDRD/STRD; Factor out common code"
This reverts commit r241928. This caused http://llvm.org/PR24190
------------------------------------------------------------------------
------------------------------------------------------------------------
r242735 | matze | 2015-07-20 16:17:20 -0700 (Mon, 20 Jul 2015) | 3 lines
Revert "ARMLoadStoreOptimizer: Create LDRD/STRD on thumb2"
This reverts commit r241926. This caused http://llvm.org/PR24190
------------------------------------------------------------------------
------------------------------------------------------------------------
r242742 | matze | 2015-07-20 17:18:59 -0700 (Mon, 20 Jul 2015) | 7 lines
ARMLoadStoreOptimizer: Create LDRD/STRD on thumb2
Re-apply r241926 with an additional check that r13 and r15 are not used
for LDRD/STRD. See http://llvm.org/PR24190. This also already includes
the fix from r241951.
Differential Revision: http://reviews.llvm.org/D10623
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@242907 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r242722 | dim | 2015-07-20 15:24:40 -0700 (Mon, 20 Jul 2015) | 6 lines
Avoid early pipefail exits due to grep failures in stage comparisons.
If objects or executables did not contain any RPATH, grep would return
nonzero, and the whole stage comparison loop would unexpectedly exit.
Fix this by checking the grep result explicitly.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@242861 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r242721 | dim | 2015-07-20 15:07:27 -0700 (Mon, 20 Jul 2015) | 4 lines
Since BSD cmp(1) does not support the --ignore-initial option, use the
more portable 3rd and 4th arguments to skip the first 16 bytes during
the comparison of Phase2 and Phase3 objects.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@242860 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r242673 | tstellar | 2015-07-20 07:28:41 -0700 (Mon, 20 Jul 2015) | 11 lines
AMDGPU/SI: Add VI patterns to select FLAT instructions for global memory ops
Summary:
The MUBUF addr64 bit has been removed on VI, so we must use FLAT
instructions when the pointer is stored in VGPRs.
Reviewers: arsenm
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11067
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@242685 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r242433 | tstellar | 2015-07-16 12:40:07 -0700 (Thu, 16 Jul 2015) | 11 lines
AMDPGU/SI: Use AssertZext node to mask high bit for scratch offsets
Summary:
We can safely assume that the high bit of scratch offsets will never
be set, because this would require at least 128 GB of GPU memory.
Reviewers: arsenm
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11225
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@242683 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r242281 | chandlerc | 2015-07-15 01:53:29 -0700 (Wed, 15 Jul 2015) | 21 lines
[PM/AA] Fix *numerous* serious bugs in GlobalsModRef found by
inspection.
While we want to handle calls specially in this code because they should
have been modeled by the call graph analysis that precedes it, we should
*not* be re-implementing the predicates for whether an instruction reads
or writes memory. Those are well defined already. Notably, at least the
following issues seem to be clearly missed before:
- Ordered atomic loads can "write" to memory by causing writes from other
threads to become visible. Similarly for ordered atomic stores.
- AtomicRMW instructions quite obviously both read and write to memory.
- AtomicCmpXchg instructions also read and write to memory.
- Fences read and write to memory.
- Invokes of intrinsics or memory allocation functions.
I don't have any test cases, and I suspect this has never really come up
in the real world. But there is no reason why it wouldn't, and it makes
the code simpler to do this the right way.
While here, I've tried to make the loops significantly simpler as well
and added helpful comments as to what is going on.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@242570 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r242296 | wschmidt | 2015-07-15 08:45:30 -0700 (Wed, 15 Jul 2015) | 37 lines
[PPC64LE] Fix vec_sld semantics for little endian
The vec_sld interface provides access to the vsldoi instruction.
Unlike most of the vec_* interfaces, we do not attempt to change the
generated code for vec_sld based on the endian mode. It is too
difficult to correctly infer the desired semantics because of
different element types, and the corrected instruction sequence is
expensive, involving loading a permute control vector and performing a
generalized permute.
For GCC, this was implemented as "Don't touch the vec_sld"
implementation. When it came time for the LLVM implementation, I did
the same thing. However, this was hasty and incorrect. In LLVM's
version of altivec.h, vec_sld was previously defined in terms of the
vec_perm interface. Because vec_perm semantics are adjusted for
little endian, this means that leaving vec_sld untouched causes it to
generate something different for LE than for BE. Not good.
This back-end patch accompanies the changes to altivec.h that change
vec_sld's behavior for little endian. Those changes mean that we see
slightly different code in the back end when trying to recognize a
VSLDOI instruction in isVSLDOIShuffleMask. In particular, a
ShuffleKind of 1 (where the two inputs are identical) must now be
treated the same way as a ShuffleKind of 2 (little endian with
different inputs) when little endian mode is in force. This is
because ShuffleKind of 1 is defined using big-endian numbering.
This has a ripple effect on LowerBUILD_VECTOR, where we create our own
internal VSLDOI instructions. Because these are a ShuffleKind of 1,
they will now have their shift amounts subtracted from 16 when
recognizing the shuffle mask. To avoid problems we have to subtract
them from 16 again before creating the VSLDOI instructions.
There are a couple of other uses of BuildVSLDOI, but these do not need
to be modified because the shift amount is 8, which is unchanged when
subtracted from 16.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@242530 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r242442 | wschmidt | 2015-07-16 14:14:07 -0700 (Thu, 16 Jul 2015) | 14 lines
[PowerPC] v4i32 is a VSRCRegClass
I was looking at some vector code generation and kept seeing
unnecessary vector copies into the Altivec half of the VSX registers.
I discovered that we overlooked v4i32 when adding the register classes
for VSX; we only added v4f32 and v2f64. This means that anything that
canonicalizes into v4i32 (which is a LOT of stuff) ends up being
forced into VRRC on its way to VSRC.
The fix is one line. The rest of the patch is fixing up some test
cases whose code generation has changed as a result.
This seems like it would be a good candidate for backport to 3.7.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@242447 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r242341 | hans | 2015-07-15 15:18:25 -0700 (Wed, 15 Jul 2015) | 7 lines
test-release.sh: Run both .o files through sed before comparing them
On some systems (e.g. Mac OS X), sed will add a newline to the end of
the output if there wasn't one already. This would cause false
cmp errors since the .o file from Phase 2 was passed through sed and
the one from Phase 3 wasn't. Work around this by passing both through
sed.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@242361 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r242331 | hans | 2015-07-15 14:06:16 -0700 (Wed, 15 Jul 2015) | 17 lines
Switch the release script to build with CMake by default (PR21561)
It retains the possibility to use the autoconf build with a
command-line option ('-use-autoconf'), and uses that by default on Darwin since
compiler-rt requires it on that platform.
This commit also removes the "Release-64" flavour and related logic. The script
would previously do two builds unless the '-no-64bit' flag was passed, but on
my machine and from those I asked this always ended up producing two 64-bit builds,
causing much confusion.
It also removes the -build-triple option, which caused the --build= flag to
get passed to ./configure. This was presumably intended for cross-compiling,
but none of the release testers use it. If someone does want to pass it,
they can use '-configure-flags --build=foo' instead.
Differential Revision: http://reviews.llvm.org/D10715
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@242360 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r242288 | d0k | 2015-07-15 05:56:19 -0700 (Wed, 15 Jul 2015) | 3 lines
[PPC] Disassemble little endian ppc instructions in the right byte order
PR24122. The test is simply a byte swapped version of ppc64-encoding.txt.
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@242327 91177308-0d34-0410-b5e6-96231b3b80d8
------------------------------------------------------------------------
r242239 | hfinkel | 2015-07-14 15:53:11 -0700 (Tue, 14 Jul 2015) | 4 lines
[PowerPC] Support symbolic targets in patchpoints
Follow-up r235483, with the corresponding support in PPC. We use a regular call
for symbolic targets (because they're much cheaper than indirect calls).
------------------------------------------------------------------------
git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_37@242325 91177308-0d34-0410-b5e6-96231b3b80d8
I am planning to add more nested classes inside RuntimePointerCheck so
all these triple-nesting would be hard to follow.
Also rename it to RuntimePointerChecking (i.e. append 'ing').
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242218 91177308-0d34-0410-b5e6-96231b3b80d8
We used to take the address specified as the direct target of the patchpoint
and did no TOC-pointer handling. This, however, as not all that useful,
because MCJIT tends to create a lot of modules, and they have their own TOC
sections. Thus, to call from the generated code to other generated code, you
really need to switch TOC pointers. Make this work as expected, and under
ELFv1, tread the address as the function descriptor address so that the correct
TOC pointer can be loaded.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242217 91177308-0d34-0410-b5e6-96231b3b80d8
For now the Archive owns the buffers of the thin archive members.
This makes for a simple API, but all the buffers are destructed
only when the archive is destructed. This should be fine since we
close the files after mmap so we should not hit an open file
limit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242215 91177308-0d34-0410-b5e6-96231b3b80d8
SelectionDAG already had begin/end methods for iterating over all
the nodes, but didn't define an iterator_range for us in foreach
loops.
This adds such a method and uses it in some of the eligible places
throughout the backends.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242212 91177308-0d34-0410-b5e6-96231b3b80d8
There was a 32-bit padding gap between 'unsigned short NumOperands, NumValues;' and 'DebugLoc debugLoc. Move 'unsigned IROrder' in to that gap.
This trims the size of SDNode's from 76 bytes (really 80 due to alignment) to 72 bytes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242211 91177308-0d34-0410-b5e6-96231b3b80d8
The simplify_type specialisation allows us to cast directly from
SDValue to an SDNode* subclass so we don't need to pass a SDNode*
to cast<>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242209 91177308-0d34-0410-b5e6-96231b3b80d8
This commit moves the function 'printReg' towards the start of the file so that
it can be used by the conversion methods in MIRPrinter and not just the printing
methods in MIPrinter.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242203 91177308-0d34-0410-b5e6-96231b3b80d8
Sometimes an incidentally created instruction can duplicate a Value used
elsewhere. It then often doesn't end up in the leader table. If it's later
removed, we attempt to remove it from the leader table and segfault.
Instead we should just ignore the removal request, which won't cause any
problems. The reverse situation, where the original instruction is replaced by
the new one (which you might think could leave the leader table empty) cannot
occur, because the incidental instruction will never be found in the first
place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242199 91177308-0d34-0410-b5e6-96231b3b80d8
MOVSDto64rr and MOV64toSDrr are defined to convert between FR64 (%xmm)
<-> GR64 registers, not VR64 (%mm) <-> GR64. This is wrong.
I found this by inspection and could not find a suitable testcase for it
since (1) we don't handle MMX bitcasts in Peephole optimizer as to
generate COPYs that (2) could be expanded back to the appropriate x86
instruction in ExpandPostRA.
Switch to use the appropriate instructions: MMX_MOVD64from64rr and
MMX_MOVD64to64rr here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242191 91177308-0d34-0410-b5e6-96231b3b80d8
PowerPC uses itineraries to describe processor pipelines (and dispatch-group
restrictions for P7/P8 cores). Unfortunately, the target-independent
implementation of TII.getInstrLatency calls ItinData->getStageLatency, and that
looks for the largest cycle count in the pipeline for any given instruction.
This, however, yields the wrong answer for the PPC itineraries, because we
don't encode the full pipeline. Because the functional units are fully
pipelined, we only model the initial stages (there are no relevant hazards in
the later stages to model), and so the technique employed by getStageLatency
does not really work. Instead, we should take the maximum output operand
latency, and that's what PPCInstrInfo::getInstrLatency now does.
This caused some test-case churn, including two unfortunate side effects.
First, the new arrangement of copies we get from function parameters now
sometimes blocks VSX FMA mutation (a FIXME has been added to the code and the
test cases), and we have one significant test-suite regression:
SingleSource/Benchmarks/BenchmarkGame/spectral-norm
56.4185% +/- 18.9398%
In this benchmark we have a loop with a vectorized FP divide, and it with the
new scheduling both divides end up in the same dispatch group (which in this
case seems to cause a problem, although why is not exactly clear). The grouping
structure is hard to predict from the bottom of the loop, and there may not be
much we can do to fix this.
Very few other test-suite performance effects were really significant, but
almost all weakly favor this change. However, in light of the issues
highlighted above, I've left the old behavior available via a
command-line flag.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242188 91177308-0d34-0410-b5e6-96231b3b80d8
* Use the default install prefix (/usr/local) and use DESTDIR instead to
set a temporary install location for tarballing. This is the correct
way to package binary releases (otherwise the temporary install path
ends up in files in the binary release).
* Remove ``-disable-clang`` option. It did not work correctly
(tarballing assumed phase 3 was run) and when doing a release
we should always be doing a three-phased build and test.
Note: Technically we should only be using DESTDIR for the third phase
and use --prefix for the first and second phase because we run the built
clang from phase 1 and 2 (and in general an application's behaviour
may depend on the install prefix). However in the case of clang it
seems to not care what the install prefix was so to simplify the script
we use DESTDIR for all three stages.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242187 91177308-0d34-0410-b5e6-96231b3b80d8
Convert logical operations on general-purpose registers to the correspon-
ding operations on predicate registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242186 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Before this change, personality directives were not emitted
if there was no invoke left in the function (of course until
recently this also meant that we couldn't know what
the personality actually was). This patch forces personality directives
to still be emitted, unless it is known to be a noop in the absence of
invokes, or the user explicitly specified `nounwind` (and not
`uwtable`) on the function.
Reviewers: majnemer, rnk
Subscribers: rnk, llvm-commits
Differential Revision: http://reviews.llvm.org/D10884
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242185 91177308-0d34-0410-b5e6-96231b3b80d8
We might not want to upgrade config.guess to the current
version due to the license change from GPL2 to GPL3.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242178 91177308-0d34-0410-b5e6-96231b3b80d8
This can be done only with moves which theoretically
will optimize better later.
Although this transform increases the instruction count,
it should be code size / cycle count neutral in the worst
VALU case. It also seems to slightly improve a couple
of testcases due to other DAG combines this exposes.
This is probably slightly worse for the SALU case, so
it might be better to handle this during moveToVALU,
although then you lose some simplifications like
the load width reducing in the simple testcase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@242177 91177308-0d34-0410-b5e6-96231b3b80d8
