| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
| |
python bindings.
For example, this prevents errors on systems that disable python because
the system python isn't available. Without this, we still try to install
things and get install errors when that doesn't work.
llvm-svn: 211899
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a fix to the code in clang which inserts padding arguments to
ensure that the ARM backend can emit AAPCS-VFP compliant code. This code
needs to track the number of registers which have been allocated in order
to do this. When passing a very large struct (>64 bytes) by value, clang
emits IR which takes a pointer to the struct, but the backend converts this
back to passing the struct in registers and on the stack. The bug was that
this was being considered by clang to only use one register, meaning that
there were situations in which padding arguments were incorrectly emitted
by clang.
llvm-svn: 211898
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've run into a bug where current LLVM at -O0 (with fast-isel)
generated invalid code like:
ld 0, 20936(1) # 8-byte Folded Reload
stw 12, 10348(0)
stw 12, 10344(0)
The underlying vreg had been introduced as base register by the
Local Stack Slot Allocation pass. That register was constrained
to G8RC by PPCRegisterInfo::materializeFrameBaseRegister to match
the ADDI instruction used to set it, but it was *not* constrained
to G8RC_NOX0 to fit the *use* of the register in an address.
That should have happened in PPCRegisterInfo::resolveFrameIndex.
This patch adds an appropriate constrainRegClass call.
Reviewed by Hal Finkel.
llvm-svn: 211897
|
| |
|
|
|
|
|
| |
A new flag to control stack trace size for store event (in
track-origins=2 mode) independently of malloc_context_size.
llvm-svn: 211896
|
| |
|
|
| |
llvm-svn: 211895
|
| |
|
|
| |
llvm-svn: 211894
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The NEON intrinsics in arm_neon.h are designed to work on vectors
"as-if" loaded by (V)LDR. We load vectors "as-if" (V)LD1, so the
intrinsics are currently incorrect.
This patch adds big-endian versions of the intrinsics that does the
"obvious but dumb" thing of reversing all vector inputs and all
vector outputs. This will produce extra REVs, but we trust the
optimizer to remove them.
llvm-svn: 211893
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This allows it to fold pshufd instructions across intervening
half-shuffles and other noise. This pattern actually shows up in the
generic lowering tests, but I've also added direct tests using
intrinsics to make sure that the specific desired functionality is
working even if the lowering stuff changes in the future.
Differential Revision: http://reviews.llvm.org/D4292
llvm-svn: 211892
|
| |
|
|
|
|
| |
ELFObjectFile:getArch() method.
llvm-svn: 211891
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
half-shuffles, even looking through intervening instructions in a chain.
Summary:
This doesn't happen to show up with any test cases I've found for the current
shuffle lowering, but previous attempts would benefit from this and it seems
generally useful. I've tested it directly using intrinsics, which also shows
that it will work with hand vectorized code as well.
Note that even though pshufd isn't directly used in these tests, it gets
exercised because we combine some of the half shuffles into a pshufd
first, and then merge them.
Differential Revision: http://reviews.llvm.org/D4291
llvm-svn: 211890
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
trivially redundant.
This fixes several cases in the new vector shuffle lowering algorithm
which would generate redundant shuffle instructions for the sake of
simplicity.
I'm also deleting a testcase which was somewhat ridiculous. It was
checking for a bug in 2007 about incorrectly transforming shuffles by
looking for the string "-86" in the output of a pretty substantial
function. This test case doesn't seem to have any value at this point.
Differential Revision: http://reviews.llvm.org/D4240
llvm-svn: 211889
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
x86 backend.
This sketches out a new code path for vector lowering, hidden behind an
off-by-default flag while it is under development. The fundamental idea
behind the new code path is to aggressively break down the problem space
in ways that ease selecting the odd set of instructions available on
x86, and carefully avoid scalarizing code even when forced to use older
ISAs. Notably, this starts off restricting itself to SSE2 and implements
the complete vector shuffle and blend space for 128-bit vectors in SSE2
without scalarizing. The plan is to layer on top of this ISA extensions
where we can bail out of the complex SSE2 lowering and opt for
a cheaper, specialized instruction (or set of instructions). It also
needs to be generalized to AVX and AVX512 vector widths.
Currently, this does a decent but not perfect job for SSE2. There are
some specific shortcomings that I plan to address:
- We need a peephole combine to fold together shuffles where possible.
There are cases where a previous shuffle could be modified slightly to
arrange for elements to be in the correct position and a later shuffle
eliminated. Doing this eagerly added quite a bit of complexity, and
so my plan is to combine away these redundancies afterward.
- There are a lot more clever ways to use unpck and pack that need to be
added. This is essential for real world shuffles as it turns out...
Once SSE2 is polished a bit I should be able to get interesting numbers
on performance improvements on benchmarks conducive to vectorization.
All of this will be off by default until it is functionally equivalent
of course.
Differential Revision: http://reviews.llvm.org/D4225
llvm-svn: 211888
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This unbreaks our internal build after these tests were turned on in r211738.
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: benlangmuir, cfe-commits
Differential Revision: http://reviews.llvm.org/D4311
llvm-svn: 211887
|
| |
|
|
| |
llvm-svn: 211886
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Current PPC64 RuntimeDyld code to handle TOC relocations has two
problems:
- With recent linkers, in addition to the relocations that implicitly
refer to the TOC base (R_PPC64_TOC*), you can now also use the .TOC.
magic symbol with any other relocation to refer to the TOC base
explicitly. This isn't currently used much in ELFv1 code (although
it could be), but it is essential in ELFv2 code.
- In a complex JIT environment with multiple modules, each module may
have its own .toc section, and TOC relocations in one module must
refer to *its own* TOC section. The current findPPC64TOC implementation
does not correctly implement this; in fact, it will always return the
address of the first TOC section it finds anywhere. (Note that at the
time findPPC64TOC is called, we don't even *know* which module the
relocation originally resided in, so it is not even possible to fix
this routine as-is.)
This commit fixes both problems by handling TOC relocations earlier, in
processRelocationRef. To do this, I've removed the findPPC64TOC routine
and replaced it by a new routine findPPC64TOCSection, which works
analogously to findOPDEntrySection in scanning the sections of the
ObjImage provided by its caller, processRelocationRef. This solves the
issue of finding the correct TOC section associated with the current
module.
This makes it straightforward to implement both R_PPC64_TOC relocations,
and relocations explicitly refering to the .TOC. symbol, directly in
processRelocationRef. There is now a new problem in implementing the
R_PPC64_TOC16* relocations, because those can now in theory involve
*three* different sections: the relocation may be applied in section A,
refer explicitly to a symbol in section B, and refer implicitly to the
TOC section C. The final processing of the relocation thus may only
happen after all three of these sections have been assigned final
addresses. There is currently no obvious means to implement this in
its general form with the common-code RuntimeDyld infrastructure.
Fortunately, ppc64 code usually makes no use of this most general form;
in fact, TOC16 relocations are only ever generated by LLVM for symbols
residing themselves in the TOC, which means "section B" == "section C"
in the above terminology. This special case can easily be handled with
the current infrastructure, and that is what this patch does.
[ Unhandled cases result in an explicit error, unlike the current code
which silently returns the wrong TOC base address ... ]
This patch makes the JIT work on both BE and LE (ELFv2 requires
additional patches, of course), and allowed me to successfully run
complex JIT scenarios (via mesa/llvmpipe).
Reviewed by Hal Finkel.
llvm-svn: 211885
|
| |
|
|
| |
llvm-svn: 211884
|
| |
|
|
| |
llvm-svn: 211883
|
| |
|
|
|
|
| |
java_finalizer is failing on all sanitizer bots since it was added in r211829.
llvm-svn: 211882
|
| |
|
|
|
|
|
|
|
|
|
|
| |
subtraction (Part 3)
This patch enables transforms for
(x + (~(y | c) + 1) --> x - (y | c) if c is odd
Differential Revision: http://reviews.llvm.org/D4210
llvm-svn: 211881
|
| |
|
|
|
|
| |
Update all callers and uses accordingly.
llvm-svn: 211880
|
| |
|
|
|
|
|
|
|
| |
The test added in r211762 was sloppy, the correct initializer wasn't
added to @llvm.global_ctors
Spotted by Pasi Parviainen!
llvm-svn: 211879
|
| |
|
|
|
|
|
| |
This is a leftover from the times when the next (chained) origin id
was stored as the last frame of a stack trace.
llvm-svn: 211878
|
| |
|
|
|
|
|
|
| |
SystemZRegisterInfo and replace it with the subtarget as that's
all they needed in the first place. Update all uses and calls
accordingly.
llvm-svn: 211877
|
| |
|
|
|
|
|
|
| |
When we create a crashdump involving modules, we build a VFS to
reproduce the problem with. This updates the reproduction script to
use that VFS.
llvm-svn: 211876
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enabling -keep-going in ScopDetection causes expansion to an invalid
Scop candidate.
Region A <- Valid candidate
|
Region B <- Invalid candidate
If -keep-going is enabled, ScopDetection would expand A to A+B because
the RejectLog is never checked for errors during expansion.
With this patch only A becomes a valid Scop.
llvm-svn: 211875
|
| |
|
|
|
|
|
| |
This function is copying the entire file contents into memory repeatedly and
allocating new file IDs *each time* a source location is processed.
llvm-svn: 211874
|
| |
|
|
|
|
|
|
|
|
|
| |
caller has debug info but the call itself has no debug location."""
Reverting this again, didn't mean to commit it - while r211872 fixes one
of the issues here, there are still others to figure out and address.
This reverts commit r211871.
llvm-svn: 211873
|
| |
|
|
|
|
| |
are promoted.
llvm-svn: 211872
|
| |
|
|
|
|
|
|
| |
debug info but the call itself has no debug location.""
This reverts commit r211724.
llvm-svn: 211871
|
| |
|
|
|
|
|
| |
than a target machine since it doesn't need anything past the
DataLayout.
llvm-svn: 211870
|
| |
|
|
| |
llvm-svn: 211869
|
| |
|
|
|
|
|
|
| |
Replace adhoc inline implementation of llvm::array_lengthof in favour of the
implementation in LLVM. This is simply a cleanup change, no functional change
intended.
llvm-svn: 211868
|
| |
|
|
| |
llvm-svn: 211867
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the behaviour of the driver for linking to match that of the
Generic_GCC::Assemble. The default link should use "ld" rather than "gcc" for
the linker as gcc does. This avoids the unnecessary round-tripping through gcc.
It also is much more reasonable behaviour from the user's perspective. This
should have been updated with SVN r195554 which changed the behaviour of
Generic_GCC::Assemble.
The gcc_forward test needs to be updated to mark the fact that -march is a flag
for GCC not ld. This was updated as a typo fix, but added a check for a flag
that is not a link flag.
The bindings test covers the change for testing, and thus no new test was added.
llvm-svn: 211866
|
| |
|
|
|
|
|
|
| |
Fixe for Bug 20057 - Assertion failied in llvm::SUnit* llvm::SchedBoundary::pickOnlyChoice(): Assertion `i <= (HazardRec->getMaxLookAhead() + MaxObservedStall) && "permanent hazard"'
Thanks to Chad for the test case.
llvm-svn: 211865
|
| |
|
|
| |
llvm-svn: 211864
|
| |
|
|
|
|
|
| |
than a target machine since it doesn't need anything past the
DataLayout.
llvm-svn: 211863
|
| |
|
|
|
|
| |
Requires supporting changes from LLVM r211861.
llvm-svn: 211862
|
| |
|
|
|
|
|
|
|
|
| |
clang was needlessly duplicating whole memory buffer contents in an attempt to
satisfy unclear ownership semantics. Let's just hide internal LLVM quirks and
present a simple non-owning interface.
The public C API preserves previous behaviour for stability.
llvm-svn: 211861
|
| |
|
|
|
|
| |
to the subtarget.
llvm-svn: 211860
|
| |
|
|
|
|
|
| |
More complicated GEPs are skipped. Add some tests to
actually stress this skipping.
llvm-svn: 211859
|
| |
|
|
|
|
| |
of the cached target machine.
llvm-svn: 211858
|
| |
|
|
|
|
| |
review from Samuel F Antao.
llvm-svn: 211857
|
| |
|
|
| |
llvm-svn: 211856
|
| |
|
|
|
|
|
|
| |
Add the new AppContainer characteristic which is import for Windows Store
(Metro) compatible applications. Add the new Control Flow Guard flag to bring
the enumeration up to date with the current values as of Windows 8.1.
llvm-svn: 211855
|
| |
|
|
|
|
| |
Make the comment layout more uniform. NFC.
llvm-svn: 211854
|
| |
|
|
|
|
|
| |
At least this answers the question of whether .bc/.ll input processed by the
frontend produces identical output to the original compilation.
llvm-svn: 211853
|
| |
|
|
|
|
|
|
| |
Any uses of tools/lto as a static lib should probably move to lib/LTO.
This was also never implemented in the configure build, so this reduces
the differences among the two.
llvm-svn: 211852
|
| |
|
|
| |
llvm-svn: 211851
|
| |
|
|
| |
llvm-svn: 211850
|