| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
It's not entirely clear to me what this field was meant for, but it's
always false. Remove it.
llvm-svn: 228034
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
The mock tags are no longer in `dwarf::LLVMConstants`; they're in
`dwarf::Tag`.
llvm-svn: 228032
|
| |
|
|
|
|
| |
Add `dwarf::getTag()` to translate from `StringRef` to `unsigned`.
llvm-svn: 228031
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 228028
|
| |
|
|
| |
llvm-svn: 228027
|
| |
|
|
|
|
| |
patterns and updating tests.
llvm-svn: 228026
|
| |
|
|
| |
llvm-svn: 228025
|
| |
|
|
| |
llvm-svn: 228024
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
- use named constructors
- get rid of MarkAsPrologue
llvm-svn: 228021
|
| |
|
|
|
|
|
|
|
| |
mutexes."
This reverts r227997, as well as r228009. It does not pass check-clang
for me locally on Linux.
llvm-svn: 228020
|
| |
|
|
| |
llvm-svn: 228019
|
| |
|
|
| |
llvm-svn: 228018
|
| |
|
|
|
|
| |
<sanitizer/coverage_interface.h>. NFC, except for the header name change. This may break existing users, but in this case it's better this way (not too many users so far)
llvm-svn: 228017
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 228015
|
| |
|
|
|
|
|
|
| |
256bit) vpmovzx* instructions.
Differential Revision: http://reviews.llvm.org/D7251
llvm-svn: 228014
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 228012
|
| |
|
|
| |
llvm-svn: 228011
|
| |
|
|
|
|
| |
multiply intrinsics and updating tests.
llvm-svn: 228010
|
| |
|
|
|
|
| |
MSVC cannot infer move ctors yet.
llvm-svn: 228009
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
I didn't bother to fix the self-referential definitions and grammar
because my eyes started to bleed.
llvm-svn: 228004
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 228002
|
| |
|
|
| |
llvm-svn: 228001
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 227998
|
| |
|
|
|
|
|
| |
These checks detect potential deadlocks caused by inconsistent lock
ordering. The checks are implemented under the -Wthread-safety-beta flag.
llvm-svn: 227997
|
| |
|
|
|
|
| |
This reverts r227994
llvm-svn: 227996
|
| |
|
|
| |
llvm-svn: 227995
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 227993
|
| |
|
|
|
|
|
|
|
| |
LoopVectorizationLegality::{getNumLoads,getNumStores} should forward to
LoopAccessAnalysis now.
Thanks to Takumi for noticing this!
llvm-svn: 227992
|
| |
|
|
|
|
| |
making the style consistent with the rest
llvm-svn: 227991
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
These are VOP2 on SI and VOP3 on VI, and their pseudos are neither, which can
be a problem. In order to make isVOP2 and isVOP3 queries behave as expected,
the encoding must be determined first.
This doesn't fix any known issue, but better safe than sorry.
v2: add and use getMCOpcodeFromPseudo
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 227987
|
| |
|
|
|
|
|
|
|
|
| |
This fixes a hang when using an empty geometry shader.
v2: - don't add s_nop when followed by s_waitcnt
- comestic changes
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 227986
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instructions (PR22371).
r224330 introduced a bug by misinterpreting the "FeatureVectorUAMem" bit.
The commit log says that change did not affect anything, but that's not correct.
That change allowed SSE instructions to have unaligned mem operands folded into
math ops, and that's not allowed in the default specification for any SSE variant.
The bug is exposed when compiling for an AVX-capable CPU that had this feature
flag but without enabling AVX codegen. Another mistake in r224330 was not adding
the feature flag to all AVX CPUs; the AMD chips were excluded.
This is part of the fix for PR22371 ( http://llvm.org/bugs/show_bug.cgi?id=22371 ).
This feature bit is SSE-specific, so I've renamed it to "FeatureSSEUnalignedMem".
Changed the existing test case for the feature bit to reflect the new name and
renamed the test file itself to better reflect the feature.
Added runs to fold-vex.ll to check for the failing codegen.
Note that the feature bit is not set by default on any CPU because it may require a
configuration register setting to enable the enhanced unaligned behavior.
llvm-svn: 227983
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thou shall not jump into SEH blocks. Jumping out of SEH __try and __excepts
is A-ok. Jumping out of __finally blocks is B-ok (msvc doesn't error about it,
but warns that it has undefined behavior).
I've checked that clang's behavior with this patch matches msvc's behavior.
We don't have the warning on jumping out of a __finally yet, see the FIXME
in the test. clang also currently crashes on codegen for a jump out of a
__finally block, see PR22414 comment 7.
I also added a few tests for the interaction of indirect jumps and SEH blocks.
MSVC doesn't support indirect jumps, so there's no way to know if clang behave
the same way as msvc here. clang's behavior with this patch does make sense
to me, but maybe it could be argued that it should be more permissive (see
FIXME in the indirect jump tests -- shout if you have an opinion on this).
llvm-svn: 227982
|
| |
|
|
| |
llvm-svn: 227981
|