| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 187271
|
| |
|
|
| |
llvm-svn: 187268
|
| |
|
|
|
|
| |
handled by the SelectionDAG store-vectorizer, which does a better job in deciding when to vectorize.
llvm-svn: 187267
|
| |
|
|
|
|
| |
as <3 x float>, because we dont have a good cost model for these types.
llvm-svn: 187265
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change makes test with RUN lines like
RUN: opt ... | FileCheck
fail if opt fails, even if it prints what FileCheck wants. Enabling this
found some interesting cases of broken tests that were not being noticed
because opt (or some other tool) was crashing late.
Pipefail is used when the shell supports it or when using the internal
python based tester.
llvm-svn: 187261
|
| |
|
|
| |
llvm-svn: 187260
|
| |
|
|
|
|
| |
This reverts commit r187248. It broke many bots.
llvm-svn: 187254
|
| |
|
|
| |
llvm-svn: 187253
|
| |
|
|
|
|
| |
tablegen.
llvm-svn: 187252
|
| |
|
|
| |
llvm-svn: 187250
|
| |
|
|
|
|
|
| |
also worthwhile for it to look through FP extensions and truncations, whose
application commutes with fneg.
llvm-svn: 187249
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Both GCC and LLVM will implicitly define __ppc__ and __powerpc__ for
all PowerPC targets, whether 32- or 64-bit. They will both implicitly
define __ppc64__ and __powerpc64__ for 64-bit PowerPC targets, and not
for 32-bit targets. We cannot be sure that all other possible
compilers used to compile Clang/LLVM define both __ppc__ and
__powerpc__, for example, so it is best to check for both when relying
on either inside the Clang/LLVM code base.
This patch makes sure we always check for both variants. In addition,
it fixes one unnecessary check in lib/Target/PowerPC/PPCJITInfo.cpp.
(At least one of __ppc__ and __powerpc__ should always be defined when
compiling for a PowerPC target, no matter which compiler is used, so
testing for them is unnecessary.)
There are some places in the compiler that check for other variants,
like __POWERPC__ and _POWER, and I have left those in place. There is
no need to add them elsewhere. This seems to be in Apple-specific
code, and I won't take a chance on breaking it.
There is no intended change in behavior; thus, no test cases are
added.
llvm-svn: 187248
|
| |
|
|
| |
llvm-svn: 187247
|
| |
|
|
| |
llvm-svn: 187245
|
| |
|
|
|
|
| |
Patch by Sasa Stankovic.
llvm-svn: 187244
|
| |
|
|
|
|
| |
register operands.
llvm-svn: 187242
|
| |
|
|
|
|
| |
Thanks to Han Finkel for noticing it.
llvm-svn: 187241
|
| |
|
|
|
|
| |
operands.
llvm-svn: 187238
|
| |
|
|
|
|
|
|
| |
We used to call Verify before adding DICompileUnit to the list, and now we
remove the check and always add DICompileUnit to the list in DebugInfoFinder,
so we can verify them later on.
llvm-svn: 187237
|
| |
|
|
| |
llvm-svn: 187234
|
| |
|
|
|
|
|
|
|
| |
to have register FCC0 (the first floating point condition code register) in
their Uses/Defs list.
No intended functionality change.
llvm-svn: 187233
|
| |
|
|
|
|
|
|
| |
needed. The generic method printOperand will do.
No functionality change.
llvm-svn: 187231
|
| |
|
|
|
|
|
|
|
|
| |
instructions "beqz", "bnez" and "move", when possible.
beq $2, $zero, $L1 => beqz $2, $L1
bne $2, $zero, $L1 => bnez $2, $L1
or $2, $3, $zero => move $2, $3
llvm-svn: 187229
|
| |
|
|
| |
llvm-svn: 187226
|
| |
|
|
|
|
| |
for consistency.
llvm-svn: 187225
|
| |
|
|
| |
llvm-svn: 187224
|
| |
|
|
|
|
|
|
| |
These were reverted in r167222 along with the rest
of the last different address space pointer size attempt.
These will be used in later commits.
llvm-svn: 187223
|
| |
|
|
|
|
| |
endian independent.
llvm-svn: 187222
|
| |
|
|
| |
llvm-svn: 187217
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
type units.
Initially this support is used in the computation of an ODR checker
for C++. For now we're attaching it to the DIE, but in the future
it will be attached to the type unit.
This also starts breaking out types into the separation for type
units, but without actually splitting the DIEs.
In preparation for hashing the DIEs this adds a DIEString type
that contains a StringRef with the string contained at the label.
llvm-svn: 187213
|
| |
|
|
| |
llvm-svn: 187212
|
| |
|
|
|
|
|
|
|
|
| |
On Windows, this improves clean cmake configuration time on my
workstation from 1m58s to 1m32s, which is pretty significant. There's
probably more that can be done here, but this is the low hanging fruit.
Eric volunteered to regenerate ./configure for me.
llvm-svn: 187209
|
| |
|
|
|
|
| |
Thanks to Hal Finkel for finding the bug and for the initial patch.
llvm-svn: 187208
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Remove LLVM_ENABLE_CRT_REPORT. LLVM_DISABLE_CRASH_REPORT made it redundant.
* set Return to 1, so that we get a stack trace on failure.
* don't call _exit, so that we get a negative exit value and "not --crash"
correctly differentiates crashes and regular errors.
This is a bit experimental since the documentation on this interface is sparse.
It doesn't bring up a dialog on my windows setup, but feel free to revert
if it causes problem for your setup (and let me know what it is so that I
can try to fix this patch).
llvm-svn: 187206
|
| |
|
|
|
|
| |
These tests fail without it if pipefail is enabled.
llvm-svn: 187205
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
CustomLowerNode was not being called during SplitVectorOperand,
meaning custom legalization could not be used by targets.
This also adds a test case for NVPTX that depends on this custom
legalization.
Differential Revision: http://llvm-reviews.chandlerc.com/D1195
Attempt to fix the buildbots by making the X86 test I just added platform independent
llvm-svn: 187202
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 187198. It broke the bots.
The soft float test probably needs a -triple because of name differences.
On the hard float test I am getting a "roundss $1, %xmm0, %xmm0", instead of
"vroundss $1, %xmm0, %xmm0, %xmm0".
llvm-svn: 187201
|
| |
|
|
|
|
|
|
|
|
|
|
| |
CustomLowerNode was not being called during SplitVectorOperand,
meaning custom legalization could not be used by targets.
This also adds a test case for NVPTX that depends on this custom
legalization.
Differential Revision: http://llvm-reviews.chandlerc.com/D1195
llvm-svn: 187198
|
| |
|
|
| |
llvm-svn: 187195
|
| |
|
|
| |
llvm-svn: 187193
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
robust. It now uses an InstVisitor and worklist to actually walk the
uses of the Alloca transitively and detect the pattern which we can
directly promote: loads & stores of the whole alloca and instructions we
can completely ignore.
Also, with this new implementation teach both the predicate for testing
whether we can promote and the promotion engine itself to use the same
code so we no longer have strange divergence between the two code paths.
I've added some silly test cases to demonstrate that we can handle
slightly more degenerate code patterns now. See the below for why this
is even interesting.
Performance impact: roughly 1% regression in the performance of SROA or
ScalarRepl on a large C++-ish test case where most of the allocas are
basically ready for promotion. The reason is because of silly redundant
work that I've left FIXMEs for and which I'll address in the next
commit. I wanted to separate this commit as it changes the behavior.
Once the redundant work in removing the dead uses of the alloca is
fixed, this code appears to be faster than the old version. =]
So why is this useful? Because the previous requirement for promotion
required a *specific* visit pattern of the uses of the alloca to verify:
we *had* to look for no more than 1 intervening use. The end goal is to
have SROA automatically detect when an alloca is already promotable and
directly hand it to the mem2reg machinery rather than trying to
partition and rewrite it. This is a 25% or more performance improvement
for SROA, and a significant chunk of the delta between it and
ScalarRepl. To get there, we need to make mem2reg actually capable of
promoting allocas which *look* promotable to SROA without have SROA do
tons of work to massage the code into just the right form.
This is actually the tip of the iceberg. There are tremendous potential
savings we can realize here by de-duplicating work between mem2reg and
SROA.
llvm-svn: 187191
|
| |
|
|
|
|
| |
have gone in lately.
llvm-svn: 187188
|
| |
|
|
|
|
| |
in a subsequent patch.
llvm-svn: 187187
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bitcode representation attribute kinds are encoded into / decoded from
should be independent of the current set of LLVM attributes and their position
in the AttrKind enum. This patch explicitly encodes attributes to fixed bitcode
values.
With this patch applied, LLVM does not silently misread attributes written by
LLVM 3.3. We also enhance the decoding slightly such that an error message is
printed if an unknown AttrKind encoding was dected.
Bonus: Dropping bitcode attributes from AttrKind is now easy, as old AttrKinds
do not need to be kept to support the Bitcode reader.
llvm-svn: 187186
|
| |
|
|
|
|
| |
static tables.
llvm-svn: 187182
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch provides basic support for powerpc64le as an LLVM target.
However, use of this target will not actually generate little-endian
code. Instead, use of the target will cause the correct little-endian
built-in defines to be generated, so that code that tests for
__LITTLE_ENDIAN__, for example, will be correctly parsed for
syntax-only testing. Code generation will otherwise be the same as
powerpc64 (big-endian), for now.
The patch leaves open the possibility of creating a little-endian
PowerPC64 back end, but there is no immediate intent to create such a
thing.
The LLVM portions of this patch simply add ppc64le coverage everywhere
that ppc64 coverage currently exists. There is nothing of any import
worth testing until such time as little-endian code generation is
implemented. In the corresponding Clang patch, there is a new test
case variant to ensure that correct built-in defines for little-endian
code are generated.
llvm-svn: 187179
|
| |
|
|
| |
llvm-svn: 187166
|
| |
|
|
| |
llvm-svn: 187164
|
| |
|
|
|
|
| |
functional changes intended.
llvm-svn: 187159
|
| |
|
|
|
|
|
| |
structure not just a pointer. This implements that and thus fixes va_copy
on PPC32. Fixes #15286. Both bug and patch by Florian Zeitz!
llvm-svn: 187158
|