| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211888 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211885 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211883 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211881 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Update all callers and uses accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211880 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
SystemZRegisterInfo and replace it with the subtarget as that's
all they needed in the first place. Update all uses and calls
accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211877 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211873 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
are promoted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211872 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
debug info but the call itself has no debug location.""
This reverts commit r211724.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211871 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
than a target machine since it doesn't need anything past the
DataLayout.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211870 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211869 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211867 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211865 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211864 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
than a target machine since it doesn't need anything past the
DataLayout.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211863 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211861 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
to the subtarget.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211860 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
of the cached target machine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211858 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211850 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Future patches will want to custom lower loads on SI.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211848 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
file in preparation for the subtarget move.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211847 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Adjust the constructor accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211846 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
be shorter and identical in goal.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211845 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
update constructor accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211840 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
that it's after.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211839 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211838 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
prototype for the function to patch what we were returning).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211837 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
the subtarget for the MSP430 target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211836 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
both MSP430InstrInfo and MSP430RegisterInfo. Remove unused member
variable StackAlign from MSP430RegisterInfo. Update constructors
accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211835 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211830 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
| |
For now I used a separate template for these sub-vector/tuple broadcasts
rather than sharing the mem variants with avx512_int_broadcast_rm.
<rdar://problem/17402869>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211828 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
make the constructor more general since it only needs a target
machine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211827 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
| |
than a target machine since it doesn't need anything past the
DataLayout.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211826 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
machine to the subtarget.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211824 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
target machine since that's all it needs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211822 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
but a normal TargetMachine and remove a few cached uses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211821 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211820 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
remove the unused constructor argument.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211819 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
cache it on the target as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211818 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211817 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
| |
There is no need to calculate the liveness information for stackmaps. The
liveness information is still available for the patchpoint intrinsic and
that is also the intended usage model.
Related to <rdar://problem/17473725>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211816 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
destruction the same way ELFObjectImage does.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211815 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
Temporarily back out commits r211749, r211752 and r211754.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211814 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
| |
for the Sparc port. Use the same initializeSubtargetDependencies
function to handle initialization similar to the other ports to
handle dependencies.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211811 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
that's all it needs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211810 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
lowering code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211809 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
|
|
|
|
|
| |
If both instructions to be replaced are marked invariant the resulting
instruction is invariant.
rdar://13358910
Fix by Erik Eckstein!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211801 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
| |
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211800 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
rather than the target machine.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211799 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
|
|
|
|
| |
includes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211798 91177308-0d34-0410-b5e6-96231b3b80d8
|