| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Handle an implied 'sp' operand.
rdar://11466783
llvm-svn: 175940
|
|
|
|
|
|
|
|
|
| |
instructions.
The Printer will now print instructions with the correct alignment specifier syntax, like
vld1.8 {d16}, [r0:64]
llvm-svn: 175884
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to TargetFrameLowering, where it belongs. Incidentally, this allows us
to delete some duplicated (and slightly different!) code in TRI.
There are potentially other layering problems that can be cleaned up
as a result, or in a similar manner.
The refactoring was OK'd by Anton Korobeynikov on llvmdev.
Note: this touches the target interfaces, so out-of-tree targets may
be affected.
llvm-svn: 175788
|
|
|
|
| |
llvm-svn: 175775
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
s/AddDirectiveHandler/addDirectiveHandler/
s/ParseMSInlineAsm/parseMSInlineAsm/
s/ParseIdentifier/parseIdentifier/
s/ParseStringToEndOfStatement/parseStringToEndOfStatement/
s/ParseEscapedString/parseEscapedString/
s/EatToEndOfStatement/eatToEndOfStatement/
s/ParseExpression/parseExpression/
s/ParseParenExpression/parseParenExpression/
s/ParseAbsoluteExpression/parseAbsoluteExpression/
s/CheckForValidSection/checkForValidSection/
http://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly
No functional change intended.
llvm-svn: 175675
|
|
|
|
|
|
|
|
|
|
|
| |
http://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly
ivars should be camel-case and start with an upper-case letter. A few in
TargetLowering were starting with a lower-case letter.
No functional change intended.
llvm-svn: 175667
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is possible that frame pointer is not found in the
callee saved info, thus FramePtrSpillFI may be incorrect
if we don't check the result of hasFP(MF).
Besides, if we enable the stack coloring algorithm, there
will be an assertion to ensure the slot is live. But in
the test case, %var1 is not live in the prologue of the
function, and we will get the assertion failure.
Note: There is similar code in ARMFrameLowering.cpp.
llvm-svn: 175616
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In my previous commit:
"Merge a f32 bitcast of a v2i32 extractelt
A vectorized sitfp on doubles will get scalarized to a sequence of an
extract_element of <2 x i32>, a bitcast to f32 and a sitofp.
Due to the the extract_element, and the bitcast we will uneccessarily generate
moves between scalar and vector registers."
I added a pattern containing a copy_to_regclass. The copy_to_regclass is
actually not needed.
radar://13191881
llvm-svn: 175555
|
|
|
|
|
|
|
|
|
| |
When creating an allocation hint for a register pair, make sure the hint
for the physical register reference is still in the allocation order.
rdar://13240556
llvm-svn: 175541
|
|
|
|
| |
llvm-svn: 175527
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A vectorized sitfp on doubles will get scalarized to a sequence of an
extract_element of <2 x i32>, a bitcast to f32 and a sitofp.
Due to the the extract_element, and the bitcast we will uneccessarily generate
moves between scalar and vector registers.
The patch fixes this by using a COPY_TO_REGCLASS and a EXTRACT_SUBREG to extract
the element from the vector instead.
radar://13191881
llvm-svn: 175520
|
|
|
|
|
|
|
|
| |
If the memcpy has an odd length with an alignment of 2, this would incorrectly
assert on the last 1 byte copy.
rdar://13202135
llvm-svn: 175459
|
|
|
|
| |
llvm-svn: 175371
|
|
|
|
|
|
| |
new features.
llvm-svn: 175336
|
|
|
|
| |
llvm-svn: 175322
|
|
|
|
|
|
|
| |
When we're recalculating the feature set of the subtarget, we need to have the
ivars in their initial state.
llvm-svn: 175320
|
|
|
|
| |
llvm-svn: 175315
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
assembler should also accept a two arg form, as the docuemntation specifies that
the first (destination) register is optional.
This patch uses TwoOperandAliasConstraint to add the two argument form.
It also fixes an 80-column formatting problem in:
test/MC/ARM/neon-bitwise-encoding
<rdar://problem/12909419> Clang rejects ARM NEON assembly instructions
llvm-svn: 175221
|
|
|
|
|
|
|
|
| |
inline asm with 64-bit data on ARM
Update test case to use -mtriple=arm-linux-gnueabi
llvm-svn: 175186
|
|
|
|
|
|
|
|
|
| |
The parser will now accept instructions with alignment specifiers written like
vld1.8 {d16}, [r0:64]
, while also still accepting the incorrect syntax
vld1.8 {d16}, [r0, :64]
llvm-svn: 175164
|
|
|
|
| |
llvm-svn: 175107
|
|
|
|
|
|
| |
on ARM
llvm-svn: 175088
|
|
|
|
| |
llvm-svn: 175020
|
|
|
|
|
|
|
|
|
| |
A reverse shuffle is lowered to a vrev and possibly a vext instruction (quad
word).
radar://13171406
llvm-svn: 174933
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lower reverse shuffles to a vrev64 and a vext instruction instead of the default
legalization of storing and loading to the stack. This is important because we
generate reverse shuffles in the loop vectorizer when we reverse store to an
array.
uint8_t Arr[N];
for (i = 0; i < N; ++i)
Arr[N - i - 1] = ...
radar://13171760
llvm-svn: 174929
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function is successfully handled by fast-isel. That's because function
arguments are *always* handled by SDISel. Introduce FastLowerArguments to
allow each target to provide hook to handle formal argument lowering.
As a proof-of-concept, add ARMFastIsel::FastLowerArguments to handle
functions with 4 or fewer scalar integer (i8, i16, or i32) arguments. It
completely eliminates the need for SDISel for trivial functions.
rdar://13163905
llvm-svn: 174855
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a function to target transform info to query for the cost of address
computation. The cost model analysis pass now also queries this interface.
The code in LoopVectorize adds the cost of address computation as part of the
memory instruction cost calculation. Only there, we know whether the instruction
will be scalarized or not.
Increase the penality for inserting in to D registers on swift. This becomes
necessary because we now always assume that address computation has a cost and
three is a closer value to the architecture.
radar://13097204
llvm-svn: 174713
|
|
|
|
|
|
|
|
| |
Vector selects are cheap on NEON. They get lowered to a vbsl instruction.
radar://13158753
llvm-svn: 174631
|
|
|
|
|
|
|
|
|
|
|
| |
Use the validateTargetOperandClass() hook to match literal '#0' operands in
InstAlias definitions. Previously this required per-instruction C++ munging of the
operand list, but not is handled as a natural part of the matcher. Much better.
No additional tests are required, as the pre-existing tests for these instructions
exercise the new behaviour as being functionally equivalent to the old.
llvm-svn: 174488
|
|
|
|
| |
llvm-svn: 174406
|
|
|
|
|
|
| |
Also adds some costs for vector integer float conversions.
llvm-svn: 174371
|
|
|
|
|
|
|
|
|
|
|
| |
Swift has a renaming dependency if we load into D subregisters. We don't have a
way of distinguishing between insertelement operations of values from loads and
other values. Therefore, we are pessimistic for now (The performance problem
showed up in example 14 of gcc-loops).
radar://13096933
llvm-svn: 174300
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
infrastructure on MCStreamer to test for whether there is an
MCELFStreamer object available.
This is just a cleanup on the AsmPrinter side of things, moving ad-hoc
tests of random APIs to a direct type query. But the AsmParser
completely broken. There were no tests, it just blindly cast its
streamer to an MCELFStreamer and started manipulating it.
I don't have a test case -- this actually failed on LLVM's own
regression test suite. Unfortunately the failure only appears when the
stars, compilers, and runtime align to misbehave when we read a pointer
to a formatted_raw_ostream as-if it were an MCAssembler. =/
UBSan would catch this immediately.
Many thanks to Matt for doing about 80% of the debugging work here in
GDB, Jim for helping to explain how exactly to fix this, and others for
putting up with the hair pulling that ensued during debugging it.
llvm-svn: 174118
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
isa<> and dyn_cast<>. In several places, code is already hacking around
the absence of this, and there seem to be several interfaces that might
be lifted and/or devirtualized using this.
This change was based on a discussion with Jim Grosbach about how best
to handle testing for specific MCStreamer subclasses. He said that this
was the correct end state, and everything else was too hacky so
I decided to just make it so.
No functionality should be changed here, this is just threading the kind
through all the constructors and setting up the classof overloads.
llvm-svn: 174113
|
|
|
|
|
|
|
| |
Each target implementation was needlessly recomputing the index.
Part of rdar://13076458
llvm-svn: 174083
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for AArch64 (ARM's 64-bit architecture) to
LLVM in the "experimental" category. Currently, it won't be built
unless requested explicitly.
This initial commit should have support for:
+ Assembly of all scalar (i.e. non-NEON, non-Crypto) instructions
(except the late addition CRC instructions).
+ CodeGen features required for C++03 and C99.
+ Compilation for the "small" memory model: code+static data <
4GB.
+ Absolute and position-independent code.
+ GNU-style (i.e. "__thread") TLS.
+ Debugging information.
The principal omission, currently, is performance tuning.
This patch excludes the NEON support also reviewed due to an outbreak of
batshit insanity in our legal department. That will be committed soon bringing
the changes to precisely what has been approved.
Further reviews would be gratefully received.
llvm-svn: 174054
|
|
|
|
|
|
|
|
| |
More details in this thread: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130128/163783.html
Patch by JF Bastien
llvm-svn: 173943
|
|
|
|
| |
llvm-svn: 173941
|
|
|
|
| |
llvm-svn: 173939
|
|
|
|
|
|
|
|
| |
setting of ELF header e_flags.
Contributer: Jack Carter
llvm-svn: 173885
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and update ELF header e_flags.
Currently gathering information such as symbol,
section and data is done by collecting it in an
MCAssembler object. From MCAssembler and MCAsmLayout
objects ELFObjectWriter::WriteObject() forms and
streams out the ELF object file.
This patch just adds a few members to the MCAssember
class to store and access the e_flag settings. It
allows for runtime additions to the e_flag by
assembler directives. The standalone assembler can
get to MCAssembler from getParser().getStreamer().getAssembler().
This patch is the generic infrastructure and will be
followed by patches for ARM and Mips for their target
specific use.
Contributer: Jack Carter
llvm-svn: 173882
|
|
|
|
|
|
|
|
|
|
|
| |
Changing ARMBaseTargetMachine to return ARMTargetLowering intead of
the generic one (similar to x86 code).
Tests showing which instructions were added to cast when necessary
or cost zero when not. Downcast to 16 bits are not lowered in NEON,
so costs are not there yet.
llvm-svn: 173849
|
|
|
|
|
|
|
|
| |
The ARM and Thumb variants of LDREXD and STREXD have different constraints and
take different operands. Previously the code expanding atomic operations didn't
take this into account and asserted in Thumb mode.
llvm-svn: 173780
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
conditions are met:
1. They share the same operand and are in the same BB.
2. Both outputs are used.
3. The target has a native instruction that maps to ISD::FSINCOS node or
the target provides a sincos library call.
Implemented the generic optimization in sdisel and enabled it for
Mac OSX. Also added an additional optimization for x86_64 Mac OSX by
using an alternative entry point __sincos_stret which returns the two
results in xmm0 / xmm1.
rdar://13087969
PR13204
llvm-svn: 173755
|
|
|
|
|
|
| |
If the sutraction of the higher 32 bit parts gives a 0 result, we need to do the store operation.
llvm-svn: 173437
|
|
|
|
|
|
| |
Refactor the big if/else sequence into one string switch for ARM subtype selection.
llvm-svn: 172475
|
|
|
|
|
|
|
|
| |
cortex-m0, cortex-m3, and cortex-m4 on the backend side.
Adds new subtype values for the MachO format and use them when the related triple are set.
llvm-svn: 172472
|
|
|
|
| |
llvm-svn: 172011
|
|
|
|
|
|
| |
instruction to determine the max vectorization factor.
llvm-svn: 172010
|
|
|
|
|
|
|
| |
address space. Reordered the EmitULEB128IntValue arguments to
make this easier.
llvm-svn: 171949
|