This adds support for the "sync $L" instruction with operand,
and provides aliases for "lwsync" and "ptesync".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185344 91177308-0d34-0410-b5e6-96231b3b80d8
I believe the full "dmb ish" barrier is not required to guarantee release
semantics for atomic operations. The weaker "dmb ishst" prevents previous
operations being reordered with a store executed afterwards, which is enough.
A key point to note (fortunately already correct) is that this barrier alone is
*insufficient* for sequential consistency, no matter how liberally placed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185339 91177308-0d34-0410-b5e6-96231b3b80d8
Since we were explicitly not calling AsmPrinter::doInitialization,
any module-scope inline asm was not being printed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185336 91177308-0d34-0410-b5e6-96231b3b80d8
We are using virtual registers throughout now, but we still need
to keep a few physical registers per class around to keep the
infrastructure happy.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185334 91177308-0d34-0410-b5e6-96231b3b80d8
Fix a case where we were incorrectly sign-extending a value when we should have been zero-extending the value.
Also change some SIGN_EXTEND to ANY_EXTEND because we really dont care and may have more opportunity to fold subexpressions
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185331 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes PR16418, which reports that a function calling
__builtin_unwind_init() asserts. The cause is that this generates a
spill/restore for VRSAVE, and we support that only on Darwin (because VRSAVE is
only really used on Darwin).
The test case checks only that we don't crash. We can add correctness checks
once someone verifies what behavior the function is supposed to have.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185235 91177308-0d34-0410-b5e6-96231b3b80d8
Change assert("text") to assert(0 && "text"). The first case is a const char *
to bool conversion, which always evaluates to true, never triggering the
assert. The second case will always trigger the assert.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185227 91177308-0d34-0410-b5e6-96231b3b80d8
Patch By: Alex Deucher
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185209 91177308-0d34-0410-b5e6-96231b3b80d8
Based on GCC's output for TLS variables (OP_constNu, x@dtpoff,
OP_lo_user), this implements debug info support for TLS in ELF. Verified
that this output is correct/sufficient on Linux (using gold - if you're
using binutils-ld, you'll need something with the fix for
http://sourceware.org/bugzilla/show_bug.cgi?id=15685 in it).
Support on non-ELF is sort of "arbitrary" at the moment - if Apple folks
want to discuss (or just go ahead & implement) how this should work in
MachO, etc, I'm open.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185203 91177308-0d34-0410-b5e6-96231b3b80d8
Under certain (evidently rare) circumstances, this code used to convert OR(a,
AND(x, y)) into OR(a, x). This was incorrect.
While there, I've added a comment to the code immediately above.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185201 91177308-0d34-0410-b5e6-96231b3b80d8
Fix ABI handling for function
returning bool -- use st.param.b32 to return the value
and use ld.param.b32 in caller to load the return value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185177 91177308-0d34-0410-b5e6-96231b3b80d8
This patch assigns paired GPRs for inline asm with
64-bit data on ARM. It's enabled for both ARM and Thumb to support modifiers
like %H, %Q, %R.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185169 91177308-0d34-0410-b5e6-96231b3b80d8
We were generating intrinsics for NEON fixed-point conversions that didn't
exist (e.g. float -> i16). There are two cases to consider:
+ iN is smaller than float. In this case we can do the conversion but need an
extend or truncate as well.
+ iN is larger than float. In this case using the NEON conversion would be
incorrect so we don't perform any combining.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185158 91177308-0d34-0410-b5e6-96231b3b80d8
The mapping between SRS pseudo-instructions and SRS native instructions was incorrect, the correct mapping is:
srsfa -> srsib
srsea -> srsia
srsfd -> srsdb
srsed -> srsda
This fixes <rdar://problem/14214734>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185155 91177308-0d34-0410-b5e6-96231b3b80d8
No functionality change.
It should suffice to check the type of a debug info metadata, instead of
calling Verify. For cases where we know the type of a DI metadata, use
assert.
Also update testing cases to make them conform to the format of DI classes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185135 91177308-0d34-0410-b5e6-96231b3b80d8
Add pseudo conditional store instructions, so that we use:
branch foo:
store
foo:
instead of:
load
branch foo:
move
foo:
store
z196 has real 32-bit and 64-bit conditional stores, but we don't use
any z196 instructions yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185065 91177308-0d34-0410-b5e6-96231b3b80d8
function to lookup the proper tablegen'ed register enumeration. Previously,
it was using the encoded value directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185026 91177308-0d34-0410-b5e6-96231b3b80d8
(Currently, ARM 'this'-returns are handled in the standard calling convention case by treating R0 as preserved and doing some extra magic in LowerCallResult; this may not apply to calling conventions added in the future so this patch provides and documents an interface for indicating such)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185024 91177308-0d34-0410-b5e6-96231b3b80d8
No functionality change.
It should suffice to check the type of a debug info metadata, instead of
calling Verify.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@185020 91177308-0d34-0410-b5e6-96231b3b80d8
Unfortunately this addresses two issues (by the time I'd disentangled the logic
it wasn't worth putting it back to half-broken):
+ Coprocessor instructions should all be predicable in Thumb mode.
+ BKPT should never be predicable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184965 91177308-0d34-0410-b5e6-96231b3b80d8
The barrier instructions are only "always-execute" in ARM mode, they can quite
happily sit inside an IT block in Thumb.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184964 91177308-0d34-0410-b5e6-96231b3b80d8
The assembler currently strictly verifies that immediates for
s16imm operands are in range (-32768 ... 32767). This matches
the behaviour of the GNU assembler, with one exception: gas
allows, as a special case, operands in an extended range
(-65536 .. 65535) for the addis instruction only (and its
extended mnemonic lis).
The main reason for this seems to be to allow using unsigned
16-bit operands for lis, e.g. like lis %r1, 0xfedc.
Since this has been supported by gas for a long time, and
assembler source code seen "in the wild" actually exploits
this feature, this patch adds equivalent support to LLVM
for compatibility reasons.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184946 91177308-0d34-0410-b5e6-96231b3b80d8
Currently, all instructions taking s16imm operands support symbolic
operands. However, for u16imm operands, we only support actual
immediate integers. This causes the assembler to reject code like
ori %r5, %r5, symbol@l
This patch changes the u16imm operand definition to likewise
accept symbolic operands. In fact, s16imm and u16imm can
share the same encoding routine, now renamed to getImm16Encoding.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184944 91177308-0d34-0410-b5e6-96231b3b80d8
Add VK_... values and relocation types necessary to support
the @got family of modifiers. Used by the asm parser only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184860 91177308-0d34-0410-b5e6-96231b3b80d8
By default, we expand these operations for both EG and SI. Move the
duplicated code into a common space for now. If the targets ever actually
implement these operations as instructions, we can override that in the relevant
target.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184848 91177308-0d34-0410-b5e6-96231b3b80d8
Add test cases for both vector sizes on SI and also add v2i32 test for EG.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184846 91177308-0d34-0410-b5e6-96231b3b80d8
Also add lit test for both cases on SI, and v2i32 for evergreen.
Note: I followed the guidance of the v4i32 EG check... UREM produces really
complex code, so let's just check that the instruction was lowered
successfully.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184844 91177308-0d34-0410-b5e6-96231b3b80d8
Also add lit test for both cases on SI, and v2i32 for evergreen.
Note: I followed the guidance of the v4i32 EG check... UDIV produces really
complex code, so let's just check that the instruction was lowered
successfully.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184843 91177308-0d34-0410-b5e6-96231b3b80d8
Also add lit test for both cases on SI, and v2i32 for evergreen.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184842 91177308-0d34-0410-b5e6-96231b3b80d8
Also add lit test for both cases on SI, and v2i32 for evergreen.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184841 91177308-0d34-0410-b5e6-96231b3b80d8
Also add lit test for both cases on SI, and v2i32 for evergreen.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184840 91177308-0d34-0410-b5e6-96231b3b80d8
Also add lit test for both cases on SI, and v2i32 for evergreen.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184839 91177308-0d34-0410-b5e6-96231b3b80d8
Also add lit test for both cases on SI, and v2i32 for evergreen.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184838 91177308-0d34-0410-b5e6-96231b3b80d8
Also add lit test for both cases on SI, and v2i32 for evergreen.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184837 91177308-0d34-0410-b5e6-96231b3b80d8
This adds pattern for the rldcr and rldic instructions (the last instruction
from the rotate/shift family that were missing). They are currently used
only by the asm parser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184833 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for the extended subtract mnemonics to the asm parser:
subi
subis
subic
subic.
sub
sub.
subc
subc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184832 91177308-0d34-0410-b5e6-96231b3b80d8
In reality, some unaligned memory accesses are legal for 32-bit types and
smaller too, but it all depends on the address space. Allowing
unaligned loads/stores for > 32-bit types is mainly to prevent the
legalizer from splitting one load into multiple loads of smaller types.
https://bugs.freedesktop.org/show_bug.cgi?id=65873
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184822 91177308-0d34-0410-b5e6-96231b3b80d8
This should only make a difference in programs that use a lot of the
vector ALU instructions like BFI_INT and BIT_ALIGN. There is a slight
improvement in the phatk bitcoin mining kernel with this patch on
Evergreen (vector size == 1):
Before:
1173 Instruction Groups / 9520 dwords
After:
1167 Instruction Groups / 9510 dwords
Reviewed-by: Reviewed-by: Vincent Lejeune<vljn at ovi.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184819 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for the predicted forms of branches (+/-).
There are three cases to consider:
- Branches using a PPC::Predicate code
For these, I've added new PPC::Predicate codes corresponding
to the BO values for predicted branch forms, and updated insn
printing to print them correctly. I've also added new aliases
for the asm parser matching the new forms.
- bt/bf
I've added new aliases matching to gBC etc.
- bd(n)z variants
I've added new instruction patterns for the predicted forms.
In all cases, the new patterns are used for the asm parser only.
(The new infrastructure ought to be sufficient to allow use by
the compiler too at some point.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184754 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the bt/bf/bd(n)zt/bd(n)zf mnemonics as aliases for the
asm parser, resolving to the generic conditional patterns.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184725 91177308-0d34-0410-b5e6-96231b3b80d8
This adds instruction patterns to cover the generic forms of
the conditional branch instructions. This allows the assembler
to support the generic mnemonics.
The compiler will still generate the various specific forms
of the instruction that were already supported.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184722 91177308-0d34-0410-b5e6-96231b3b80d8
There is currently only limited support for the "absolute" variants
of branch instructions. This patch adds support for the absolute
variants of all branches that are currently otherwise supported.
This requires adding new fixup types so that the correct variant
of relocation type can be selected by the object writer.
While the compiler will continue to usually choose the relative
branch variants, this will allow the asm parser to fully support
the absolute branches, with either immediate (numerical) or
symbolic target addresses.
No change in code generation intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184721 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for the bd(n)zl and bd(n)zlrl instructions.
The patterns are currently used for the asm parser only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184720 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for the conditional variants of bl.
The pattern is currently used by the asm parser only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184719 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for blrl and its conditional variants.
The patterns are (currently) used for the asm parser only.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184718 91177308-0d34-0410-b5e6-96231b3b80d8
When encoded to thumb, VFP instruction and VMOV/VDUP between scalar and
core registers, must have their predicate bit to 0b1110.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184707 91177308-0d34-0410-b5e6-96231b3b80d8
In thumb1, NOP is a pseudo-instruction equivalent to mov r8, r8.
However the disassembler should not use this alias.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184703 91177308-0d34-0410-b5e6-96231b3b80d8
This is an awful implementation of the target hook. But we don't have
abstractions yet for common machine ops, and I don't see any quick way
to make it table-driven.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184664 91177308-0d34-0410-b5e6-96231b3b80d8
A FastISel optimization was causing us to emit no information for such
parameters & when they go missing we end up emitting a different
function type. By avoiding that shortcut we not only get types correct
(very important) but also location information (handy) - even if it's
only live at the start of a function & may be clobbered later.
Reviewed/discussion by Evan Cheng & Dan Gohman.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184604 91177308-0d34-0410-b5e6-96231b3b80d8
IR for CUDA should use "nvptx[64]-nvidia-cuda", and IR for NV OpenCL should use "nvptx[64]-nvidia-nvcl"
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184579 91177308-0d34-0410-b5e6-96231b3b80d8
The GNU assembler supports (as extension to the ABI) use of PC-relative
relocations in half16 fields, which allows writing code like:
li 1, base-.
This patch adds support for those relocation types in the assembler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184552 91177308-0d34-0410-b5e6-96231b3b80d8
The current code base only supports the minimum set of tls-related
relocations and @modifiers that are necessary to support compiler-
generated code. This patch extends this to the full set defined
in the ABI (and supported by the GNU assembler) for the benefit
of the assembler parser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184551 91177308-0d34-0410-b5e6-96231b3b80d8
This adds support for the @higher, @highera, @highest, and @highesta
modifers, including some missing relocation types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184550 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the relocation type and other necessary infrastructure
to use the @toc@h modifier in the assembler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184549 91177308-0d34-0410-b5e6-96231b3b80d8
This adds necessary infrastructure to support the @h modifier.
Note that all required relocation types were already present
(and unused).
This patch provides support for using @h in the assembler;
it would also be possible to now use this feature in code
generated by the compiler, but this is not done yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184548 91177308-0d34-0410-b5e6-96231b3b80d8
This renames more VK_PPC_ enums, to make them more closely reflect
the @modifier string they represent. This also prepares for adding
a bunch of new VK_PPC_ enums in upcoming patches.
For consistency, some MO_ flags related to VK_PPC_ enums are
likewise renamed.
No change in behaviour.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184547 91177308-0d34-0410-b5e6-96231b3b80d8
it at the moment.
This allows to form more paired loads even when stack coloring pass destroys the
memoryoperand's value.
<rdar://problem/13978317>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184492 91177308-0d34-0410-b5e6-96231b3b80d8
This is another minor cleanup; to bring enum names in line
with the corresponding @modifier names, this renames:
VK_PPC_TOC -> VK_PPC_TOCBASE
VK_PPC_TOC_ENTRY -> VK_PPC_TOC16
No code change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184491 91177308-0d34-0410-b5e6-96231b3b80d8
This is a bit tricky as the xacquire and xrelease hints use the same bytes,
0xf2 and 0xf3, as the repne and rep prefixes.
Fortunately llvm has different llvm MCInst Opcode enums for rep/xrelease
and repne/xacquire. So to make this work a boolean was added the
InternalInstruction struct as part of the Prefix state which is set with the
added logic in readPrefixes() when decoding an instruction to determine
if these prefix bytes are to be disassembled as xacquire or xrelease. Then
we let the matcher pick the normal prefix instructionID and we change the
Opcode after that when it is set into the MCInst being created.
rdar://11019859
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184490 91177308-0d34-0410-b5e6-96231b3b80d8
This just re-sorts the big switch statement in
PPCELFObjectWriter::getRelocTypeInner to follow
the (numerical) order of the reloc types, and
fixes a couple of whitespace issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184485 91177308-0d34-0410-b5e6-96231b3b80d8
Also add a v2i32 test to the existing v4i32 test.
Patch by: Aaron Watry
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Aaron Watry<awatry@gmail.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184482 91177308-0d34-0410-b5e6-96231b3b80d8
Also add SI tests to existing file and a v2i32 test for both
R600 and SI.
Patch by: Aaron Watry
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Aaron Watry <awatry@gmail.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184481 91177308-0d34-0410-b5e6-96231b3b80d8
The custom lowering causes llc to crash with a segfault.
Ideally, the custom lowering can be fixed, but this allows
programs which load/store v2i32 to work without crashing.
Patch by: Aaron Watry
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Aaron Watry<awatry@gmail.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184480 91177308-0d34-0410-b5e6-96231b3b80d8
The cdp2 instruction should have the same restrictions as cdp on the
co-processor registers.
VFP instructions on v8/AArch32 share the same encoding space as cdp2.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184445 91177308-0d34-0410-b5e6-96231b3b80d8
The isDarwin parameter to the llvm::LowerPPCMachineInstrToMCInst
routine is now no longer needed; remove it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184441 91177308-0d34-0410-b5e6-96231b3b80d8
This (hopefully) fixes build failures resulting from r184436;
the PowerPC asm parser now depends on PowerPC target expresssions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184439 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for having the assembler optimize fixups
to constructs like "symbol@ha" or "symbol@l" if "symbol" can be
resolved at assembler time.
This optimization is already present in the PPCMCExpr.cpp code
for handling PPC_HA16/PPC_LO16 target expressions. However,
those target expression were used only on Darwin targets.
This patch changes target expression code so that they are
usable also with the GNU assembler (using the @ha / @l syntax
instead of the ha16() / lo16() syntax), and changes the
MCInst lowering code to generate those target expressions
where appropriate.
It also changes the asm parser to generate HA16/LO16 target
expressions when parsing assembler source that uses the
@ha / @l modifiers. The effect is that now the above-
mentioned optimization automatically becomes available
for those situations too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184436 91177308-0d34-0410-b5e6-96231b3b80d8
We had been papering over a problem with location info for non-trivial
types passed by value by emitting their type as references (this caused
the debugger to interpret the location information correctly, but broke
the type of the function). r183329 corrected the type information but
lead to the debugger interpreting the pointer parameter as the value -
the debug info describing the location needed an extra dereference.
Use a new flag in DIVariable to add the extra indirection (either by
promoting an existing DW_OP_reg (parameter passed in a register) to
DW_OP_breg + 0 or by adding DW_OP_deref to an existing DW_OP_breg + n
(parameter passed on the stack).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184368 91177308-0d34-0410-b5e6-96231b3b80d8
Said assert assumes that ADDC will always have a glue node as its second
argument and is checked before we even know that we are actually performing the
relevant MLAL optimization. This is incorrect since on ARM we *CAN* codegen ADDC
with a use list based second argument. Thus to have both effects, I converted
the assert to a conditional check which if it fails we do not perform the
optimization.
In terms of tests I can not produce an ADDC from the IR level until I get in my
multiprecision optimization patch which is forthcoming. The tests for said patch
would cause this assert to fail implying that said tests will provide the
relevant tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184230 91177308-0d34-0410-b5e6-96231b3b80d8
"When assembling to the ARM instruction set, the .N qualifier produces
an assembler error and the .W qualifier has no effect."
In the pre-matcher handler in the asm parser the ".w" (wide) qualifier
when in ARM mode is now discarded. And an error message is now
produced when the ".n" (narrow) qualifier is used in ARM mode.
Test cases for these were added.
rdar://14064574
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184224 91177308-0d34-0410-b5e6-96231b3b80d8
When producing objects that are abi compliant we are
marking neither the object file nor the assembly file
correctly and thus generate warnings.
We need to set the EF_CPIC flag in the ELF header when
generating direct object.
Note that the warning is only generated when compiling without PIC.
When compiling with clang the warning will be suppressed by supplying:
-Wa,-mno-shared -Wa,-call_nonpic
Also the following directive should also be added:
.option pic0
when compiling without PIC, This eliminates the need for supplying:
-mno-shared -call_nonpic
on the assembler command line.
Patch by Douglas Gilmore
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184220 91177308-0d34-0410-b5e6-96231b3b80d8
For decoding, keep the current behavior of always decoding these as their REP
versions. In the future, this could be improved to recognize the cases where
these behave as XACQUIRE and XRELEASE and decode them as such.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184207 91177308-0d34-0410-b5e6-96231b3b80d8
When using a positive offset, literal loads where encoded
as if it was negative, because:
- The sign bit was not assigned to an operand
- The addrmode_imm12 operand was not encoding the sign bit correctly
This patch also makes the assembler look at the .w/.n specifier for
loads.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184182 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes two previous issues:
- Negative offsets were not correctly disassembled
- The decoded opcodes were not the right one
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184180 91177308-0d34-0410-b5e6-96231b3b80d8
Someone may want to do something crazy, like replace these objects if they
change or something.
No functionality change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184175 91177308-0d34-0410-b5e6-96231b3b80d8
Frame index handling is now target-agnostic, so delete the target hooks
for creation & asm printing of target-specific addressing in DBG_VALUEs
and any related functions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184067 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than using the full power of target-specific addressing modes in
DBG_VALUEs with Frame Indicies, simply use Frame Index + Offset. This
reduces the complexity of debug info handling down to two
representations of values (reg+offset and frame index+offset) rather
than three or four.
Ideally we could ensure that frame indicies had been eliminated by the
time we reached an assembly or dwarf generation, but I haven't spent the
time to figure out where the FIs are leaking through into that & whether
there's a good place to convert them. Some FI+offset=>reg+offset
conversion is done (see PrologEpilogInserter, for example) which is
necessary for some SelectionDAG assumptions about registers, I believe,
but it might be possible to make this a more thorough conversion &
ensure there are no remaining FIs no matter how instruction selection
is performed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184066 91177308-0d34-0410-b5e6-96231b3b80d8
Replace the ill-defined MinLatency and ILPWindow properties with
with straightforward buffer sizes:
MCSchedMode::MicroOpBufferSize
MCProcResourceDesc::BufferSize
These can be used to more precisely model instruction execution if desired.
Disabled some misched tests temporarily. They'll be reenabled in a few commits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184032 91177308-0d34-0410-b5e6-96231b3b80d8
Also add a seperate vector lit test file, since r600 doesn't seem to handle
v2i32 load/store yet, but we can test both for SI.
Patch by: Aaron Watry
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Aaron Watry <awatry@gmail.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184021 91177308-0d34-0410-b5e6-96231b3b80d8
We were using RAT_INST_STORE_RAW, which seemed to work, but the docs
say this instruction doesn't exist for Cayman, so it's probably safer
to use a documented instruction instead.
Reviewed-by: Vincent Lejeune<vljn at ovi.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184015 91177308-0d34-0410-b5e6-96231b3b80d8
This is a resubmit of r182877, which was reverted because it broken
MCJIT tests on ARM. The patch leaves MCJIT on ARM as it was before: only
enabled for iOS. I've CC'ed people from the original review and revert.
FastISel was only enabled for iOS ARM and Thumb2, this patch enables it
for ARM (not Thumb2) on Linux and NaCl, but not MCJIT.
Thumb2 support needs a bit more work, mainly around register class
restrictions.
The patch punts to SelectionDAG when doing TLS relocation on non-Darwin
targets. I will fix this and other FastISel-to-SelectionDAG failures in
a separate patch.
The patch also forces FastISel to retain frame pointers: iOS always
keeps them for backtracking (so emitted code won't change because of
this), but Linux was getting much worse code that was incorrect when
using big frames (such as test-suite's lencod). I'll also fix this in a
later patch, it will probably require a peephole so that FastISel
doesn't rematerialize frame pointers back-to-back.
The test changes are straightforward, similar to:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130513/174279.html
They also add a vararg test that got dropped in that change.
I ran all of lnt test-suite on A15 hardware with --optimize-option=-O0
and all the tests pass. All the tests also pass on x86 make check-all. I
also re-ran the check-all tests that failed on ARM, and they all seem to
pass.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183966 91177308-0d34-0410-b5e6-96231b3b80d8
Now that the PRED_BAD has been removed, this is failing the Clang
-Werror build due to -Wcovered-switch-default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183863 91177308-0d34-0410-b5e6-96231b3b80d8
I'm taking David Blaikie's suggestion to use an
Optional<PPC::Predicate> return value instead. That's the right
solution for this problem. Thanks for pointing out that possibility!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183858 91177308-0d34-0410-b5e6-96231b3b80d8
This is a preparatory patch for fast-isel support. The instruction
selector will need to access some functions in PPCGenCallingConv.inc,
which in turn requires several helper functions to be defined. These
are currently defined near the only use of PCCGenCallingConv.inc,
inside PPCISelLowering.cpp. This patch moves the declaration of the
functions into the associated header file to provide the needed
visibility.
No functional change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183844 91177308-0d34-0410-b5e6-96231b3b80d8
Allows returning a PPC::Predicate from a function with a no-predicate
value possible. Preparatory patch for fast-isel on PPC64 ELF. No
behavioral change intended.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183841 91177308-0d34-0410-b5e6-96231b3b80d8
I've been comparing the object file output of LLVM's integrated
assembler against the external assembler on PowerPC, and one
area where differences still remain are in DWARF sections.
In particular, the GNU assembler generates .debug_frame and
.debug_line sections using a code alignment factor of 4, since
all PowerPC instructions have size 4 and must be aligned to a
multiple of 4. However, current MC code hard-codes a code
alignment factor of 1.
This patch changes this by adding a "minimum instruction alignment"
data element to MCAsmInfo and using this as code alignment factor.
This requires passing a MCContext into MCDwarfLineAddr::Encode
and MCDwarfLineAddr::EncodeAdvanceLoc. Note that one caller,
MCDwarfLineAddr::Write, didn't actually have that information
available. However, it turns out that this routine is in fact
never used in the whole code base, so the patch simply removes
it. If it turns out to be needed again at a later time, it
could be re-added with an updated interface.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183834 91177308-0d34-0410-b5e6-96231b3b80d8
The pass emits a call to sqrt that has attribute "read-none". This call will be
converted to an ISD::FSQRT node during DAG construction, which will turn into
a mips native sqrt instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183802 91177308-0d34-0410-b5e6-96231b3b80d8
Sign- and zero-extension folding was slightly incorrect because it wasn't checking that the shift on extensions was zero. Further, I recently added AND rd, rn, #255 as a form of 8-bit zero extension, and failed to add the folding code for it.
This patch fixes both issues.
This patch fixes both, and the test should remain the same:
test/CodeGen/ARM/fast-isel-fold.ll
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183794 91177308-0d34-0410-b5e6-96231b3b80d8
Negative zero is returned by the primary expression parser as INT32_MIN, so all that the method needs to do is to accept this value.
Behavior already present for Thumb2.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183734 91177308-0d34-0410-b5e6-96231b3b80d8
- Don't use assert(0), or tests may pass or fail according to assertions.
- For now, The tests are marked as XFAIL for win32 hosts.
FIXME: Could we avoid XFAIL to specify triple in the RUN lines?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183728 91177308-0d34-0410-b5e6-96231b3b80d8
Some ARM CPUs only support ARM mode (ancient v4 ones, for example) and some
only support Thumb mode (M-class ones currently). This makes sure such CPUs
default to the correct mode and makes the AsmParser diagnose an attempt to
switch modes incorrectly.
rdar://14024354
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183710 91177308-0d34-0410-b5e6-96231b3b80d8
Previously LEA64_32r went through virtually the entire backend thinking it was
using 32-bit registers until its blissful illusions were cruelly snatched away
by MCInstLower and 64-bit equivalents were substituted at the last minute.
This patch makes it behave normally, and take 64-bit registers as sources all
the way through. Previous uses (for 32-bit arithmetic) are accommodated via
SUBREG_TO_REG instructions which make the types and classes agree properly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183693 91177308-0d34-0410-b5e6-96231b3b80d8
