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
The test added in r211762 was sloppy, the correct initializer wasn't
added to @llvm.global_ctors
Spotted by Pasi Parviainen!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211879 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
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
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
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
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211855 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211852 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
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
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
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
