What this does is that if you accidentally select these instructions on VI,
the code generation will fail, because the pseudo -> _vi mapping will be
undefined.
The idea is to be able to catch possible future bugs easily.
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 228038
with 'stress' to indicate that the specific output isn't interesting and
relax them to only check the last instruction (a ret).
I've updated the one test case that really uses this to name the one
'stress_test' which was actually producing output we can directly check.
With this, the script doesn't introduce noise when run over the v16 test
file.
llvm-svn: 228033
Also re-implements the `dwarf::Tag` enumerator. I've moved the mock
tags into the enumerator since there's no other way to do this. Really
they shouldn't be used at all (they're just a hack to identify
`MDNode`s, but we have a class hierarchy for that now).
llvm-svn: 228030
`dwarf::TagString()` shouldn't stringify `DW_TAG_lo_user` or
`DW_TAG_hi_user`. These aren't actual tags; they're markers for the
edge of vendor-specific tag regions.
llvm-svn: 228029
This reverts commit r227966, which turned ASAN on on AArhc64 and may be the
cause of the bots never finishing the check-all. I'll re-apply once we're
sure that bot can cope with it.
llvm-svn: 228023
This patch adds general shuffle pattern matching for the MOVQ zero-extend instruction (copy lower 64bits, zero upper) for all 128-bit integer vectors, it is added as a fallback test in lowerVectorShuffleAsZeroOrAnyExtend.
llvm-svn: 228022
Summary:
Straight-line strength reduction (SLSR) is implemented in GCC but not yet in
LLVM. It has proven to effectively simplify statements derived from an unrolled
loop, and can potentially benefit many other cases too. For example,
LLVM unrolls
#pragma unroll
foo (int i = 0; i < 3; ++i) {
sum += foo((b + i) * s);
}
into
sum += foo(b * s);
sum += foo((b + 1) * s);
sum += foo((b + 2) * s);
However, no optimizations yet reduce the internal redundancy of the three
expressions:
b * s
(b + 1) * s
(b + 2) * s
With SLSR, LLVM can optimize these three expressions into:
t1 = b * s
t2 = t1 + s
t3 = t2 + s
This commit is only an initial step towards implementing a series of such
optimizations. I will implement more (see TODO in the file commentary) in the
near future. This optimization is enabled for the NVPTX backend for now.
However, I am more than happy to push it to the standard optimization pipeline
after more thorough performance tests.
Test Plan: test/StraightLineStrengthReduce/slsr.ll
Reviewers: eliben, HaoLiu, meheff, hfinkel, jholewinski, atrick
Reviewed By: jholewinski, atrick
Subscribers: karthikthecool, jholewinski, llvm-commits
Differential Revision: http://reviews.llvm.org/D7310
llvm-svn: 228016
Appends the username to the first component (after the temp dir) of the
module cache path. If the username contains a character that shouldn't
go into a path (for now conservatively allow [a-zA-Z0-9_]), we fallback
to the user id.
llvm-svn: 228013
This patch detects consecutive vector loads using the existing
EltsFromConsecutiveLoads() logic. This fixes:
http://llvm.org/bugs/show_bug.cgi?id=22329
This patch effectively reverts the tablegen additions of D6492 /
http://reviews.llvm.org/rL224344 ...which in hindsight were a horrible hack.
The test cases that were added with that patch are simply modified to load
from varying offsets of a base pointer. These loads did not match the existing
tablegen patterns.
A happy side effect of doing this optimization earlier is that we can now fold
the load into a math op where possible; this is shown in some of the updated
checks in the test file.
Differential Revision: http://reviews.llvm.org/D7303
llvm-svn: 228006
Before this patch, the CMake build assumed LIT_EXECUTABLE pointed
to a Python script, not an executable. If you were to pass in an
executable, such as the result of py2exe on lit.py, the build would
fall over.
With this patch, the CMake build assumes LIT_EXECUTABLE is an
executable. You can continue setting it to lit.py, but it will
now use its shebang to find a Python interpreter.
Differential Revision: http://reviews.llvm.org/D7315
llvm-svn: 228005
distinction between the different use-cases. With the previous default
behavior we would occasionally emit empty debug locations in situations
where they actually were strictly required (= on invoke insns).
We now have a choice between defaulting to an empty location or an
artificial location.
Specifically, this fixes a bug caused by a missing debug location when
emitting C++ EH cleanup blocks from within an artificial function, such as
an ObjC destroy helper function.
rdar://problem/19670595
llvm-svn: 228003
lto_codegen_compile_optimized. Also add lto_api_version.
Before this commit, we can only dump the optimized bitcode after running
lto_codegen_compile, but it includes some impacts of running codegen passes,
one example is StackProtector pass. We will get assertion failure when running
llc on the optimized bitcode, because StackProtector is effectively run twice.
After splitting lto_codegen_compile, the linker can choose to dump the bitcode
before running lto_codegen_compile_optimized.
lto_api_version is added so ld64 can check for runtime-availability of the new
API.
rdar://19565500
llvm-svn: 228000
If we are building an 64bit installer on Windows we have to adjust the
Program Files path otherwise it uses the wrong Program Files (x86)
directory. Related CMake bug report
http://public.kitware.com/Bug/view.php?id=14211
Patch by Ismail Dönmez!
llvm-svn: 227999
These checks detect potential deadlocks caused by inconsistent lock
ordering. The checks are implemented under the -Wthread-safety-beta flag.
llvm-svn: 227997
Before this patch, the CMake build assumed LIT_EXECUTABLE pointed
to a Python script, not an executable. If you were to pass in an
executable, such as the result of py2exe on lit.py, the build would
fall over.
With this patch, the CMake build assumes LIT_EXECUTABLE is an
executable. You can continue setting it to lit.py, but it will
now use its shebang to find a Python interpreter.
Differential Revision: http://reviews.llvm.org/D7315
llvm-svn: 227994
This can happen when a REV instruction is commuted.
The trick is not to define the _vi versions of instructions, which has these
consequences:
- code generation will always fail if a pseudo cannot be lowered
(very useful to catch bugs where an unsupported instruction somehow makes
it to the printer)
- ability to query if a pseudo can be lowered, which is done in commuteOpcode
to prevent REV from commuting to non-REV on VI
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 227990
The getCommute* functions are only used with pseudos, so this commit doesn't
change anything.
The issue with missing non-rev versions of shift instructions on VI will fixed
separately.
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 227989
- V_MAC_LEGACY_F32 exists on VI, but it's VOP3-only.
- Define CVT_PK opcodes which are different between SI and VI. These are
unused. The idea is to define all chip differences.
v2: keep V_MUL_LO_U32
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 227988
Marek Olsak