| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were figuring out whether to use tPICADD or PICADD, then just using
tPICADD unconditionally anyway. Oops.
A testcase from someone familiar enough with ELF to produce one would
be appreciated. The existing PIC testcase correctly verifies the .s
generated, but that doesn't catch this bug, which only showed up in
direct-to-object mode.
http://llvm.org/bugs/show_bug.cgi?id=17180
llvm-svn: 190417
|
| |
|
|
|
|
|
| |
This commit removes the unused "AttributeItem" from
ObjectAttributeEmitter.
llvm-svn: 190412
|
| |
|
|
|
|
|
|
|
| |
IT blocks can only be one instruction lonf, and can only contain a subset of
the 16 instructions.
Patch by Artyom Skrobov!
llvm-svn: 190309
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to generate the compact unwind encoding from the machine
instructions. However, this had the problem that if the user used `-save-temps'
or compiled their hand-written `.s' file (with CFI directives), we wouldn't
generate the compact unwind encoding.
Move the algorithm that generates the compact unwind encoding into the
MCAsmBackend. This way we can generate the encoding whether the code is from a
`.ll' or `.s' file.
<rdar://problem/13623355>
llvm-svn: 190290
|
| |
|
|
|
|
|
| |
This removes the custom ISD Node: MEMBARRIER and replaces it
with an intrinsic.
llvm-svn: 190055
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These were pretty straightforward instructions, with some assembly support
required for HLT.
The ARM assembler is keen to split the instruction mnemonic into a
(non-existent) 'H' instruction with the LT condition code. An exception for
HLT is needed.
HLT follows the same rules as BKPT when in IT blocks, so the special BKPT
hadling code has been adapted to handle HLT also.
Regression tests added including diagnostic tests for out of range immediates
and illegal condition codes, as well as negative tests for pre-ARMv8.
llvm-svn: 190053
|
| |
|
|
|
|
|
| |
Solution is not sufficient to prevent 'mov pc, lr' being emitted for jump table code.
Test case doesn't trigger the added functionality.
llvm-svn: 190047
|
| |
|
|
|
|
|
|
|
| |
This improves code generation for jump tables by avoiding the emission of "mov pc, lr" which could fool the processor into believing this is a return from a function causing mispredicts. The code generation logic for jump tables uses ADR to materialize the address of the jump target.
Patch by Daniel Stewart!
llvm-svn: 190043
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
These instructions, such as vmul.f32, require the second source operand to
be in D0-D15 rather than the full D0-D31. When optimizing, make sure to
account for that by constraining the register class of a replacement virtual
register to be compatible with the virtual register(s) it's replacing.
I've been unsuccessful in creating a non-fragile regression test. This issue
was detected by the LLVM nightly test suite running on an A15 (Bullet).
PR17093: http://llvm.org/bugs/show_bug.cgi?id=17093
llvm-svn: 189972
|
| |
|
|
|
|
|
|
| |
Unaligned vldm/vstm need more uops and therefore are slower in general on swift.
radar://14522102
llvm-svn: 189961
|
| |
|
|
|
|
| |
on Cortex-A9. This also makes the existing code more compact.
llvm-svn: 189958
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r189648.
Fixes for the previously failing clang-side arm_neon_intrinsics test
cases will be checked in separately.
llvm-svn: 189841
|
| |
|
|
|
|
|
|
| |
Test cases adjusted accordingly.
This fixes rdar://14871821.
llvm-svn: 189766
|
| |
|
|
|
|
| |
What we really want is to enable Swift by default for *v7s triples (and there already seems to be some logic which attempts to do that). In that case the iOS version doesn't matter.
llvm-svn: 189763
|
| |
|
|
|
|
|
|
| |
Test cases adjusted accordingly.
This fixes rdar://14871821.
llvm-svn: 189756
|
| |
|
|
| |
llvm-svn: 189728
|
| |
|
|
|
|
|
|
| |
This reverts commit r189619.
The commit was breaking the arm_neon_intrinsic test.
llvm-svn: 189648
|
| |
|
|
|
|
|
|
|
|
|
| |
In addition to recognizing when the multiply's second argument is
coming from an explicit VDUPLANE, also look for a plain scalar
f32 reference and reference it via the corresponding vector
lane.
rdar://14870054
llvm-svn: 189619
|
| |
|
|
|
|
| |
if the target is iOS and Linux.
llvm-svn: 189604
|
| |
|
|
|
|
|
|
|
|
|
| |
Fix a few things in one swoop.
# Add some negative tests.
# Fix some formatting issues.
# Add some missing IsThumb / ARMv8
# Fix some outs / ins mistakes.
llvm-svn: 189490
|
| |
|
|
|
|
|
|
| |
The usual default of "dmb ish" (inner-shareable) isn't even a valid instruction
on v6M or v7M (well, it does the same thing but software is strongly
discouraged from using it) so we should emit a full-system barrier there.
llvm-svn: 189483
|
| |
|
|
| |
llvm-svn: 189482
|
| |
|
|
|
|
|
| |
Clang is now generating cleaner IR, so this removes the old variants which
should be completely unused.
llvm-svn: 189481
|
| |
|
|
|
|
|
|
|
| |
The vqdmlal and vqdmlls instructions are really just a fused pair consisting of
a vqdmull.sN and a vqadd.sN. This adds patterns to LLVM so that we can switch
Clang's CodeGen over to generating these instead of the special vqdmlal
intrinsics.
llvm-svn: 189480
|
| |
|
|
| |
llvm-svn: 189388
|
| |
|
|
|
|
| |
Fix two issues I found while writing these tests.
llvm-svn: 189341
|
| |
|
|
|
|
|
|
| |
These instructions aren't particularly complicated and it's well worth having
patterns for some reasonably useful LLVM IR that will match them. Soon we
should be able to switch Clang over to producing this natural version.
llvm-svn: 189335
|
| |
|
|
|
|
|
|
|
| |
Object/MachOFormat.h over to Support/MachO.h."
This reverts commits r189319 and r189315. r189315 broke some tests on what I
believe are big-endian platforms.
llvm-svn: 189321
|
| |
|
|
| |
llvm-svn: 189315
|
| |
|
|
|
|
|
|
|
| |
Get the register class right for the TST instruction. This keeps the
machine verifier happy, enabling us to turn it on for another test.
rdar://12594152
llvm-svn: 189274
|
| |
|
|
|
|
|
|
|
| |
Constant pool and global value reference instructions need more
restricted register classes than plain GPR.
rdar://12594152
llvm-svn: 189270
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The create machine code wasn't properly in SSA, which the machine verifier
properly complains about. Now that fast-isel is closer to verifier clean,
errors like this show up more clearly.
Additionally, the Thumb pseudo tPICADD was used for both ARM and Thumb
mode functions, which is obviously wrong. Fix that along the way.
Test case is part of the following commit which will finish making an
additional fast-isel test verifier clean an enable it for the
regression test suite. This commit is separate since its not just
a verifier cleanup, but an actual correctness issue.
rdar://12594152 (for the fast-isel verifier aspects)
llvm-svn: 189269
|
| |
|
|
| |
llvm-svn: 189109
|
| |
|
|
| |
llvm-svn: 189103
|
| |
|
|
|
|
|
|
|
|
| |
I'd forgotten that "Requires" blocks override rather than add to the
constraints, so my pseudo-instruction was being selected in Thumb mode leading
to nonsense instructions.
rdar://problem/14817358
llvm-svn: 189096
|
| |
|
|
|
|
|
|
| |
This uses the ARMcmov pattern that Tim cleaned up in r188995.
Thanks to Simon Tatham for his floating point help!
llvm-svn: 189024
|
| |
|
|
|
|
|
|
|
|
|
| |
The instruction to convert between floating point and fixed point representations
takes an immediate operand for the number of fractional bits of the fixed point
value. ARMARM specifies that when that number of bits is zero, the assembler
should encode floating point/integer conversion instructions.
This patch adds the necessary instruction aliases to achieve this behaviour.
llvm-svn: 189009
|
| |
|
|
|
|
| |
we pass these tests with -verify-machineinstrs.
llvm-svn: 189006
|
| |
|
|
|
|
|
| |
The function call to external function should come with PLT relocation
type if the PIC relocation model is used.
llvm-svn: 189002
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Back in the mists of time (2008), it seems TableGen couldn't handle the
patterns necessary to match ARM's CMOV node that we convert select operations
to, so we wrote a lot of fairly hairy C++ to do it for us.
TableGen can deal with it now: there were a few minor differences to CodeGen
(see tests), but nothing obviously worse that I could see, so we should
probably address anything that *does* come up in a localised manner.
llvm-svn: 188995
|
| |
|
|
|
|
|
| |
The code for 'Q' and 'R' operand modifiers needs to look through tied
operands to discover the register class.
llvm-svn: 188990
|
| |
|
|
|
|
|
|
|
| |
Indirect tail-calls shouldn't use R9 for the branch destination, as
it's not reliably a call-clobbered register.
rdar://14793425
llvm-svn: 188967
|
| |
|
|
|
|
|
| |
According to the ARM specification, "mov" is a valid mnemonic for all Thumb2 MOV encodings.
To achieve this, the patch adds one instruction alias with a special range condition to avoid collision with the Thumb1 MOV.
llvm-svn: 188901
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Update testcase to be more careful about checking register
values. While regexes are general goodness for these sorts of
testcases, in this example, the registers are constrained by
the calling convention, so we can and should check their
explicit values.
rdar://14779513
llvm-svn: 188819
|
| |
|
|
|
|
|
|
| |
Previously we used a const-pool load for virtually all 64-bit floating values.
Actually, we can get quite a few common values (including 0.0, 1.0) via "vmov"
instructions of one stripe or another.
llvm-svn: 188773
|
| |
|
|
|
|
|
|
| |
The Thumb2 add immediate is in fact defined for SP. The manual is misleading as it points to a different section for add immediate with SP, however the encoding is the same as for add immediate with register only with the SP operand hard coded. As such add immediate with SP and add immediate with register can safely be treated as the same instruction.
All the patch does is adjust a register constraint on an instruction alias.
llvm-svn: 188676
|
| |
|
|
|
|
|
|
| |
When patching inlineasm nodes to use GPRPair for 64-bit values, we
were dropping the information that two operands were tied, which
effectively broke the live-interval of vregs affected.
llvm-svn: 188643
|
| |
|
|
|
|
|
|
| |
Ongoing 'make the verifier happy' improvements to ARM fast-isel.
rdar://12594152
llvm-svn: 188595
|
| |
|
|
|
|
|
|
|
|
| |
Properly constrain the operand register class for instructions used
in [sz]ext expansion. Update more tests to use the verifier now that
we're getting the register classes correct.
rdar://12594152
llvm-svn: 188594
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Teach the generic instruction selection helper functions to constrain
the register classes of their input operands. For non-physical register
references, the generic code needs to be careful not to mess that up
when replacing references to result registers. As the comment indicates
for MachineRegisterInfo::replaceRegWith(), it's important to call
constrainRegClass() first.
rdar://12594152
llvm-svn: 188593
|