| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 105860
|
| |
|
|
|
|
| |
Introduce the VEX_X field
llvm-svn: 105859
|
| |
|
|
| |
llvm-svn: 105858
|
| |
|
|
| |
llvm-svn: 105856
|
| |
|
|
|
|
|
| |
quoting problems. Not particularly ideal, but should work ok. Based on a patch by
Michael Spencer!
llvm-svn: 105855
|
| |
|
|
|
|
|
| |
i64 and f64 types, but now it also handle Neon vector types, so the f64 result
of VMOVDRR may need to be converted to a Neon type. Radar 8084742.
llvm-svn: 105845
|
| |
|
|
| |
llvm-svn: 105837
|
| |
|
|
|
|
|
|
|
|
|
| |
the machine instruction representation of the immediate value to be encoded
into an integer with similar fields as the actual VMOV instruction. This makes
things easier for the disassembler, since it can just stuff the bits into the
immediate operand, but harder for the asm printer since it has to decode the
value to be printed. Testcase for the encoding will follow later when MC has
more support for ARM.
llvm-svn: 105836
|
| |
|
|
| |
llvm-svn: 105828
|
| |
|
|
| |
llvm-svn: 105827
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the Profile method. Currently this only works with the default FoldingSetTraits
implementation.
The point of this is to allow nodes to not store context values which are only
used during profiling. A better solution would thread this value through the
folding algorithms, but then those would need to be (1) templated and
(2) non-opaque.
llvm-svn: 105819
|
| |
|
|
| |
llvm-svn: 105792
|
| |
|
|
|
|
|
| |
warnings with gcc-4.6, by not setting bits when the result is not
used.
llvm-svn: 105790
|
| |
|
|
|
|
|
|
|
|
| |
warnings
with gcc-4.6. The warning is wrong, since Sub *is* used (perhaps gcc is confused
because the use of Sub is constant folded away?), but since it is trivial to avoid,
and massively reduces the amount of warning spew, just workaround the wrong warning.
llvm-svn: 105788
|
| |
|
|
|
|
|
| |
done some more header trimming, resulting in cstdef being included
by less header files.
llvm-svn: 105786
|
| |
|
|
|
|
| |
providing more ways to factor out commonality from the records.
llvm-svn: 105776
|
| |
|
|
| |
llvm-svn: 105775
|
| |
|
|
| |
llvm-svn: 105774
|
| |
|
|
| |
llvm-svn: 105769
|
| |
|
|
|
|
|
|
| |
dbg_value immediately follows a sequence of ldr/str instructions that should
be combined into an ldm/stm and is the last instruction in the block, then
combine may end up being skipped.
llvm-svn: 105758
|
| |
|
|
| |
llvm-svn: 105750
|
| |
|
|
|
|
|
| |
This is a bit of a hack to make inline asm look more like call instructions.
It would be better to produce correct dead flags during isel.
llvm-svn: 105749
|
| |
|
|
|
|
| |
will use this to try to avoid breaking up IT blocks.
llvm-svn: 105745
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
%reg1025 = <sext> %reg1024
...
%reg1026 = SUBREG_TO_REG 0, %reg1024, 4
into this:
%reg1025 = <sext> %reg1024
...
%reg1027 = EXTRACT_SUBREG %reg1025, 4
%reg1026 = SUBREG_TO_REG 0, %reg1027, 4
The problem here is that SUBREG_TO_REG is there to assert that an implicit zext
occurs. It doesn't insert a zext instruction. If we allow the EXTRACT_SUBREG
here, it will give us the value after the <sext>, not the original value of
%reg1024 before <sext>.
llvm-svn: 105741
|
| |
|
|
| |
llvm-svn: 105740
|
| |
|
|
|
|
|
|
| |
is used to assert that an *implicit* zext is performed.
- Fix grammar-o in INSERT_SUBREG. (required reformatting)
llvm-svn: 105735
|
| |
|
|
|
|
| |
This will be used primarily by NEON shift intrinsics.
llvm-svn: 105733
|
| |
|
|
|
|
| |
green. Dan, please revert this once the real problem is fixed.
llvm-svn: 105732
|
| |
|
|
|
|
| |
refer to the "external node" instead.
llvm-svn: 105731
|
| |
|
|
|
|
|
|
| |
callgraph SCC's. This makes it match what the node itself would print. Also,
"indirect callgraph node" doesn't make sense - it has nothing particularly to
do with indirect calls.
llvm-svn: 105730
|
| |
|
|
| |
llvm-svn: 105726
|
| |
|
|
|
|
| |
can be reused from PartialSpecializationCost
llvm-svn: 105725
|
| |
|
|
|
|
| |
We default to inserting to lane 0.
llvm-svn: 105722
|
| |
|
|
|
|
| |
random load/store, rather than crashing llc.
llvm-svn: 105710
|
| |
|
|
|
|
|
|
| |
codegen.
Parenthesize macro args
llvm-svn: 105682
|
| |
|
|
| |
llvm-svn: 105677
|
| |
|
|
|
|
|
|
|
| |
'class llvm::DAGDeltaAlgorithm' has virtual functions and accessible non-virtual destructor
Not sure if this is the best solution, but this class has state and some of the
classes that inherit from it also do, so it looks appropriate.
llvm-svn: 105675
|
| |
|
|
| |
llvm-svn: 105674
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the same condition, it's important to make sure they are scheduled together
to avoid forming multiple IT blocks. I'm adding a pre-regalloc pass that forms
IT blocks early (by re-scheduling instructions and split basic blocks) to
attempt to fix this. This is not turned on by default since I am not sure this
is the right fix.
Another issue is llvm selects are modeled as two-address conditional moves.
This can be very bad when the copies before the conditional moves are not
coalesced away. Teach IT formation pass to move the copies above the IT block
(when legal) to avoid breaking the IT block.
llvm-svn: 105669
|
| |
|
|
|
|
|
|
| |
constant arguments
Handle extract hi/lo with common code
llvm-svn: 105666
|
| |
|
|
| |
llvm-svn: 105665
|
| |
|
|
|
|
|
|
|
|
|
|
| |
instruction. Added the 64-bit version "jrcxz" so it is recognized and also
added the checks for incorrect uses of "jcxz" in 64-bit mode and "jrcxz" in
32-bit mode. Still to do is to correctly handle the encoding of the
instruction adding the Address-size override prefix byte, 0x67, when the width
of the count register is not the same as the mode the machine is running in.
Which for example means the encoding of "jecxz" depends if you are assembling
as a 32-bit target or a 64-bit target.
llvm-svn: 105661
|
| |
|
|
|
|
| |
that rip-relative address when executing in 32-bit mode.
llvm-svn: 105656
|
| |
|
|
| |
llvm-svn: 105653
|
| |
|
|
|
|
| |
immediates to avoid breaking the build.
llvm-svn: 105652
|
| |
|
|
|
|
| |
the register. While we're at it, make sure it's in the right one.
llvm-svn: 105645
|
| |
|
|
|
|
| |
they are out of date, instead of only testing if they exist.
llvm-svn: 105636
|
| |
|
|
| |
llvm-svn: 105634
|
| |
|
|
| |
llvm-svn: 105620
|
| |
|
|
|
|
| |
even/odd, since adjacent changes are more likely to be related.
llvm-svn: 105613
|