| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In this case, essentially it is soft float with different library routines.
The next step will be to make this fully interoperational with mips32 floating
point and that requires creating stubs for functions with signatures that
contain floating point types.
I have a more sophisticated design for mips16 hardfloat which I hope to
implement at a later time that directly does floating point without the need
for function calls.
The mips16 encoding has no floating point instructions so one needs to
switch to mips32 mode to execute floating point instructions.
llvm-svn: 170259
|
| |
|
|
|
|
|
|
| |
immediate generates the narrow version. Needed when doing round-trip
assemble/disassemble testing using the alternate syntax that specifies
'pc' directly.
llvm-svn: 170255
|
| |
|
|
|
|
| |
because we cant type-legalize them.
llvm-svn: 170245
|
| |
|
|
|
|
|
|
|
|
| |
for TLS dynamic models on 64-bit PowerPC ELF. The default sort routine
for relocations only sorts on the r_offset field; but with TLS, there
can be two relocations with the same r_offset. For PowerPC, this patch
sorts secondarily on descending r_type, which matches the behavior
expected by the linker.
llvm-svn: 170237
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for a wider range of GOT entries that can hold thread-relative offsets.
This matches the behavior of GCC, which was not documented in the PPC64 TLS
ABI. The ABI will be updated with the new code sequence.
Former sequence:
ld 9,x@got@tprel(2)
add 9,9,x@tls
New sequence:
addis 9,2,x@got@tprel@ha
ld 9,x@got@tprel@l(9)
add 9,9,x@tls
Note that a linker optimization exists to transform the new sequence into
the shorter sequence when appropriate, by replacing the addis with a nop
and modifying the base register and relocation type of the ld.
llvm-svn: 170209
|
| |
|
|
| |
llvm-svn: 170158
|
| |
|
|
|
|
|
| |
some hackery in place that hid my poor use of TblGen, which I've now sorted
out and cleaned up. No change in observable behavior, so no new test cases.
llvm-svn: 170149
|
| |
|
|
|
|
| |
Patch by: NAKAMURA Takumi
llvm-svn: 170142
|
| |
|
|
|
|
|
| |
avoiding use of machine operand flags. No change in observable behavior, so
no new test cases.
llvm-svn: 170141
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Accordingly, add helper funtions getSimpleValueType (in parallel to
getValueType) in SDValue, SDNode, and TargetLowering.
This is the first, in a series of patches.
This is the second attempt. In the first attempt (r169837), a few
getSimpleVT() were hoisted too far, detected by bootstrap failures.
llvm-svn: 170104
|
| |
|
|
|
|
| |
internal linkage.
llvm-svn: 170092
|
| |
|
|
|
|
| |
given the section.
llvm-svn: 170087
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 170084
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 170080
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 170077
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 170076
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 170075
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 170073
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 170072
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 170071
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 170069
|
| |
|
|
|
|
| |
and separate encoding information from the rest.
llvm-svn: 170066
|
| |
|
|
|
|
| |
This function is going to be removed.
llvm-svn: 170064
|
| |
|
|
|
|
|
| |
MipsInstrFPU.td.
llvm-svn: 170061
|
| |
|
|
| |
llvm-svn: 170060
|
| |
|
|
| |
llvm-svn: 170057
|
| |
|
|
|
|
|
| |
FFR2P_M.
llvm-svn: 170055
|
| |
|
|
| |
llvm-svn: 170054
|
| |
|
|
|
|
|
|
| |
FFR1_W_M and FFR1P_M. The new instruction definitions have one-to-one
correspondence with the instructions in the ISA manual.
llvm-svn: 170053
|
| |
|
|
| |
llvm-svn: 170052
|
| |
|
|
| |
llvm-svn: 170012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PowerPC target. This is the last of the four models, so we now have
full TLS support.
This is mostly a straightforward extension of the general dynamic model.
I had to use an additional Chain operand to tie ADDIS_DTPREL_HA to the
register copy following ADDI_TLSLD_L; otherwise everything above the
ADDIS_DTPREL_HA appeared dead and was removed.
As before, there are new test cases to test the assembly generation, and
the relocations output during integrated assembly. The expected code
gen sequence can be read in test/CodeGen/PowerPC/tls-ld.ll.
There are a couple of things I think can be done more efficiently in the
overall TLS code, so there will likely be a clean-up patch forthcoming;
but for now I want to be sure the functionality is in place.
Bill
llvm-svn: 170003
|
| |
|
|
|
|
|
|
| |
Add R_ARM_NONE and R_ARM_PREL31 relocation types
to MCExpr. Both of them will be used while
generating .ARM.extab and .ARM.exidx sections.
llvm-svn: 169965
|
| |
|
|
| |
llvm-svn: 169962
|
| |
|
|
|
|
|
|
|
|
|
|
| |
mention the inline memcpy / memset expansion code is a mess?
This patch split the ZeroOrLdSrc argument into two: IsMemset and ZeroMemset.
The first indicates whether it is expanding a memset or a memcpy / memmove.
The later is whether the memset is a memset of zero. It's totally possible
(likely even) that targets may want to do different things for memcpy and
memset of zero.
llvm-svn: 169959
|
| |
|
|
|
|
|
|
|
| |
Also added more comments to explain why it is generally ok to return true.
- Rename getOptimalMemOpType argument IsZeroVal to ZeroOrLdSrc. It's meant to
be true for loaded source (memcpy) or zero constants (memset). The poor name
choice is probably some kind of legacy issue.
llvm-svn: 169954
|
| |
|
|
|
|
| |
f64 load / store on non-SSE2 x86 targets.
llvm-svn: 169944
|
| |
|
|
| |
llvm-svn: 169933
|
| |
|
|
|
|
|
| |
Pre-regalloc frame allocation and referencing has been on by default
for ages. No need for the testing option that disables it.
llvm-svn: 169931
|
| |
|
|
|
|
| |
Base pointer referencing has been enabled for ages.
llvm-svn: 169930
|
| |
|
|
|
|
|
|
|
| |
ScalarTargetTransformInfo::getIntImmCost() instead. "Legal" is a poorly defined
term for something like integer immediate materialization. It is always possible
to materialize an integer immediate. Whether to use it for memcpy expansion is
more a "cost" conceern.
llvm-svn: 169929
|
| |
|
|
|
|
| |
A new backend supporting AMD GPUs: Radeon HD2XXX - HD7XXX
llvm-svn: 169915
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Given a thread-local symbol x with global-dynamic access, the generated
code to obtain x's address is:
Instruction Relocation Symbol
addis ra,r2,x@got@tlsgd@ha R_PPC64_GOT_TLSGD16_HA x
addi r3,ra,x@got@tlsgd@l R_PPC64_GOT_TLSGD16_L x
bl __tls_get_addr(x@tlsgd) R_PPC64_TLSGD x
R_PPC64_REL24 __tls_get_addr
nop
<use address in r3>
The implementation borrows from the medium code model work for introducing
special forms of ADDIS and ADDI into the DAG representation. This is made
slightly more complicated by having to introduce a call to the external
function __tls_get_addr. Using the full call machinery is overkill and,
more importantly, makes it difficult to add a special relocation. So I've
introduced another opcode GET_TLS_ADDR to represent the function call, and
surrounded it with register copies to set up the parameter and return value.
Most of the code is pretty straightforward. I ran into one peculiarity
when I introduced a new PPC opcode BL8_NOP_ELF_TLSGD, which is just like
BL8_NOP_ELF except that it takes another parameter to represent the symbol
("x" above) that requires a relocation on the call. Something in the
TblGen machinery causes BL8_NOP_ELF and BL8_NOP_ELF_TLSGD to be treated
identically during the emit phase, so this second operand was never
visited to generate relocations. This is the reason for the slightly
messy workaround in PPCMCCodeEmitter.cpp:getDirectBrEncoding().
Two new tests are included to demonstrate correct external assembly and
correct generation of relocations using the integrated assembler.
Comments welcome!
Thanks,
Bill
llvm-svn: 169910
|
| |
|
|
| |
llvm-svn: 169854
|
| |
|
|
|
|
|
|
| |
MVTs, instead of EVTs.
Accordingly, add bitsLT (and similar) to MVT.
llvm-svn: 169850
|
| |
|
|
|
|
| |
EVTs.
llvm-svn: 169848
|
| |
|
|
|
|
| |
of EVT.
llvm-svn: 169845
|
| |
|
|
|
|
|
|
|
| |
Accordingly, add helper funtions getSimpleValueType (in parallel to
getValueType) in SDValue, SDNode, and TargetLowering.
This is the first, in a series of patches.
llvm-svn: 169837
|
| |
|
|
| |
llvm-svn: 169819
|
| |
|
|
| |
llvm-svn: 169814
|