| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
I accidentally changed the encoding of the MSA registers to zero instead of 0
to 31. This change restores the encoding the registers had prior to r188893.
This didn't show up in the existing tests because direct-object emission isn't
implemented yet for MSA.
llvm-svn: 188896
|
| |
|
|
| |
llvm-svn: 188895
|
| |
|
|
|
|
|
| |
These are extensions of the existing FI[EDX]BR instructions, but use a spare
bit to suppress inexact conditions.
llvm-svn: 188894
|
| |
|
|
|
|
| |
No functional change
llvm-svn: 188893
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Like yaml ObjectFiles, this will be very useful for testing the MC CFG
implementation (mostly MCObjectDisassembler), by matching the output
with YAML, and for potential users of the MC CFG, by using it as an input.
There isn't much to the actual format, it is just a serialization of the
MCModule class. Of note:
- Basic block references (pred/succ, ..) are represented by the BB's
start address.
- Just as in the MC CFG, instructions are MCInsts with a size.
- Operands have a prefix representing the type (only register and
immediate supported here).
- Instruction opcodes are represented by their names; enum values aren't
stable, enum names mostly are: usually, a change to a name would need
lots of changes in the backend anyway.
Same with registers.
All in all, an example is better than 1000 words, here goes:
A simple binary:
Disassembly of section __TEXT,__text:
_main:
100000f9c: 48 8b 46 08 movq 8(%rsi), %rax
100000fa0: 0f be 00 movsbl (%rax), %eax
100000fa3: 3b 04 25 48 00 00 00 cmpl 72, %eax
100000faa: 0f 8c 07 00 00 00 jl 7 <.Lend>
100000fb0: 2b 04 25 48 00 00 00 subl 72, %eax
.Lend:
100000fb7: c3 ret
And the (pretty verbose) generated YAML:
---
Atoms:
- StartAddress: 0x0000000100000F9C
Size: 20
Type: Text
Content:
- Inst: MOV64rm
Size: 4
Ops: [ RRAX, RRSI, I1, R, I8, R ]
- Inst: MOVSX32rm8
Size: 3
Ops: [ REAX, RRAX, I1, R, I0, R ]
- Inst: CMP32rm
Size: 7
Ops: [ REAX, R, I1, R, I72, R ]
- Inst: JL_4
Size: 6
Ops: [ I7 ]
- StartAddress: 0x0000000100000FB0
Size: 7
Type: Text
Content:
- Inst: SUB32rm
Size: 7
Ops: [ REAX, REAX, R, I1, R, I72, R ]
- StartAddress: 0x0000000100000FB7
Size: 1
Type: Text
Content:
- Inst: RET
Size: 1
Ops: [ ]
Functions:
- Name: __text
BasicBlocks:
- Address: 0x0000000100000F9C
Preds: [ ]
Succs: [ 0x0000000100000FB7, 0x0000000100000FB0 ]
<snip>
...
llvm-svn: 188890
|
| |
|
|
| |
llvm-svn: 188889
|
| |
|
|
| |
llvm-svn: 188888
|
| |
|
|
|
|
| |
Used to detect calls to function symbol stubs (future commit).
llvm-svn: 188887
|
| |
|
|
|
|
|
|
|
|
| |
Supports:
- entrypoint, using LC_MAIN.
- static ctors/dtors, using __mod_{init,exit}_func
- translation between effective and object load address, using
dyld's VM address slide.
llvm-svn: 188886
|
| |
|
|
|
|
|
|
| |
It can now disassemble code in situations where the effective load
address is different than the load address declared in the object file.
This happens for PIC, hence "dynamic".
llvm-svn: 188884
|
| |
|
|
|
|
|
|
|
| |
This is the behavior of sequential disassemblers (llvm-objdump, ...),
when there is no instruction size hint (fixed-length, ...)
While there, also do some minor cleanup.
llvm-svn: 188883
|
| |
|
|
|
|
| |
For now, this isn't implemented for any format.
llvm-svn: 188882
|
| |
|
|
|
|
|
|
| |
When an MCTextAtom is split, all MCBasicBlocks backed by it are
automatically split, with a fallthrough between both blocks, and
the successors moved to the second block.
llvm-svn: 188881
|
| |
|
|
|
|
| |
While there, do some minor cleanup.
llvm-svn: 188880
|
| |
|
|
|
|
|
| |
Only implemented in the Mach-O ObjectSymbolizer.
The testcase sadly introduces a new binary.
llvm-svn: 188879
|
| |
|
|
| |
llvm-svn: 188878
|
| |
|
|
| |
llvm-svn: 188876
|
| |
|
|
|
|
| |
Also, drive-by cleaning around createFunction.
llvm-svn: 188875
|
| |
|
|
| |
llvm-svn: 188874
|
| |
|
|
| |
llvm-svn: 188873
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
.debug_pubtypes version field
Summary:
LLVM would generate DWARF with version 3 in the .debug_pubname and
.debug_pubtypes version fields. This would lead SGI dwarfdump to fail
parsing the DWARF with (in the instance of .debug_pubnames) would exit
with:
dwarfdump ERROR: dwarf_get_globals: DW_DLE_PUBNAMES_VERSION_ERROR (123)
This fixes PR16950.
Reviewers: echristo, dblaikie
Reviewed By: echristo
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1454
llvm-svn: 188869
|
| |
|
|
|
|
| |
MCJIT code where CurOp was being incremented even if the operand it was pointing at wasn't used. Maybe only matters if there are any EVEX_K instructions that aren't VEX_4V.
llvm-svn: 188868
|
| |
|
|
|
|
|
|
| |
as it is always src1. This was causing the encoding of the operands to be off by one.
Patch by Chris Bieneman.
llvm-svn: 188866
|
| |
|
|
|
|
| |
av512pf, avx-512-cdi -> avx512cd, avx-512-eri->avx512er. This matches better with official docs and what gcc patches appearto be using. I didn't touch the has* functions or the feature flag names to avoid change the td and lowering file while commits are still happening.
llvm-svn: 188859
|
| |
|
|
|
|
| |
I suppose all "lli -use-mcjit i686-*" should require GOT, (and to fail.)
llvm-svn: 188856
|
| |
|
|
| |
llvm-svn: 188852
|
| |
|
|
| |
llvm-svn: 188851
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the end.
There are situations which can affect the correctness (or at least expectation)
of the gcov output. For instance, if a call to __gcov_flush() occurs within a
block before the execution count is registered and then the program aborts in
some way, then that block will not be marked as executed. This is not normally
what the user expects.
If we move the code that's registering when a block is executed to the
beginning, we can catch these types of situations.
PR16893
llvm-svn: 188849
|
| |
|
|
| |
llvm-svn: 188848
|
| |
|
|
|
|
|
|
|
|
| |
when the
size of floating point registers is 64-bit.
Test case will be added when support for mfhc1 and mthc1 is added.
llvm-svn: 188847
|
| |
|
|
| |
llvm-svn: 188845
|
| |
|
|
| |
llvm-svn: 188844
|
| |
|
|
|
|
|
|
| |
point registers. We will need this register class later when we add
definitions for instructions mfhc1 and mthc1. Also, remove sub-register indices
sub_fpeven and sub_fpodd and use sub_lo and sub_hi instead.
llvm-svn: 188842
|
| |
|
|
|
|
|
|
|
|
|
| |
Update iterator when the SLP vectorizer changes the instructions in the basic
block by restarting the traversal of the basic block.
Patch by Yi Jiang!
Fixes PR 16899.
llvm-svn: 188832
|
| |
|
|
| |
llvm-svn: 188831
|
| |
|
|
|
|
|
|
| |
load/store instructions defined. Previously, we were defining load/store
instructions for each pointer size (32 and 64-bit), but now we need just one
definition.
llvm-svn: 188830
|
| |
|
|
|
|
|
|
|
| |
functions be compiled as mips32, without having to add attributes. This
is useful in certain situations where you don't want to have to edit the
function attributes in the source. For now it's only an option used for
the compiler developers when debugging the mips16 port.
llvm-svn: 188826
|
| |
|
|
|
|
| |
assembler predicate HasStdEnd so that it is false when the target is micromips.
llvm-svn: 188824
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 188798
|
| |
|
|
| |
llvm-svn: 188786
|
| |
|
|
|
|
|
| |
These instructions were present in a draft spec but were removed before
publication.
llvm-svn: 188782
|
| |
|
|
|
|
| |
We now use MVST, CLST and SRST for the obvious cases.
llvm-svn: 188781
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SystemZTargetLowering::emitStringWrapper() previously loaded the character
into R0 before the loop and made R0 live on entry. I'd forgotten that
allocatable registers weren't allowed to be live across blocks at this stage,
and it confused LiveVariables enough to cause a miscompilation of f3 in
memchr-02.ll.
This patch instead loads R0 in the loop and leaves LICM to hoist it
after RA. This is actually what I'd tried originally, but I went for
the manual optimisation after noticing that R0 often wasn't being hoisted.
This bug forced me to go back and look at why, now fixed as r188774.
We should also try to optimize null checks so that they test the CC result
of the SRST directly. The select between null and the SRST GPR result could
then usually be deleted as dead.
llvm-svn: 188779
|
| |
|
|
| |
llvm-svn: 188778
|
| |
|
|
| |
llvm-svn: 188777
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Post-RA LICM keeps three sets of registers: PhysRegDefs, PhysRegClobbers
and TermRegs. When it sees a definition of R it adds all aliases of R
to the corresponding set, so that when it needs to test for membership
it only needs to test a single register, rather than worrying about
aliases there too. E.g. the final candidate loop just has:
unsigned Def = Candidates[i].Def;
if (!PhysRegClobbers.test(Def) && ...) {
to test whether register Def is multiply defined.
However, there was also a shortcut in ProcessMI to make sure we didn't
add candidates if we already knew that they would fail the final test.
This shortcut was more pessimistic than the final one because it
checked whether _any alias_ of the defined register was multiply defined.
This is too conservative for targets that define register pairs.
E.g. on z, R0 and R1 are sometimes used as a pair, so there is a
128-bit register that aliases both R0 and R1. If a loop used
R0 and R1 independently, and the definition of R0 came first,
we would be able to hoist the R0 assignment (because that used
the final test quoted above) but not the R1 assignment (because
that meant we had two definitions of the paired R0/R1 register
and would fail the shortcut in ProcessMI).
This patch just uses the same check for the ProcessMI shortcut as
we use in the final candidate loop.
llvm-svn: 188774
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 188772
|
| |
|
|
| |
llvm-svn: 188771
|