| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 143262
|
| |
|
|
|
|
| |
"REQUIRES: asserts" for now.
llvm-svn: 143247
|
| |
|
|
| |
llvm-svn: 143237
|
| |
|
|
|
|
|
|
|
|
|
| |
When '~imm' is encodable as a t2_so_imm but plain 'imm' is not. For example,
mov r2, #-3
becomes
mvn r2, #2
rdar://10349224
llvm-svn: 143235
|
| |
|
|
|
|
|
|
|
| |
For example,
On ARM, "mov r3, #-3" is an alias for "mvn r3, #2", so we want to use a
matcher pattern that handles the bitwise negation when mapping to t2MVNi.
llvm-svn: 143233
|
| |
|
|
| |
llvm-svn: 143231
|
| |
|
|
| |
llvm-svn: 143224
|
| |
|
|
|
|
| |
instructions.
llvm-svn: 143220
|
| |
|
|
| |
llvm-svn: 143218
|
| |
|
|
| |
llvm-svn: 143217
|
| |
|
|
|
|
|
|
|
| |
Spotted by my super-optimizer in 186.crafty and 450.soplex. We really
need a proper infrastructure for handling generalizations of this kind
of thing (which occur a lot), however this case is so simple that I decided
to go ahead and implement it directly.
llvm-svn: 143214
|
| |
|
|
| |
llvm-svn: 143213
|
| |
|
|
|
|
| |
For completeness - not spotted in the wild.
llvm-svn: 143211
|
| |
|
|
|
|
| |
in 186.crafty.
llvm-svn: 143209
|
| |
|
|
|
|
| |
inadvertantly exposed a decoding ambiguity between SWP and CPS that the auto-generated decoder can't handle.
llvm-svn: 143208
|
| |
|
|
|
|
|
|
|
| |
fixes: Use a separate register, instead of SP, as the
calling-convention resource, to avoid spurious conflicts with
actual uses of SP. Also, fix unscheduling of calling sequences,
which can be triggered by pseudo-two-address dependencies.
llvm-svn: 143206
|
| |
|
|
| |
llvm-svn: 143203
|
| |
|
|
| |
llvm-svn: 143202
|
| |
|
|
|
|
|
|
|
|
|
| |
Outside an IT block, "add r3, #2" should select a 32-bit wide encoding
rather than generating an error indicating the 16-bit encoding is only
legal in an IT block (outside, the 'S' suffic is required for the 16-bit
encoding).
rdar://10348481
llvm-svn: 143201
|
| |
|
|
|
|
|
|
| |
If the register class in the source alias is a subclass of the register class
of the actual instruction, the alias can still match OK since the constraints
are strictly a subset of what the instruction can actually handle.
llvm-svn: 143200
|
| |
|
|
|
|
|
|
| |
uses X86 instruction.
FIXME: Would it be reproduced without target-specific operands?
FIXME: Why run llvm-mc as the same input by 3 times?
llvm-svn: 143195
|
| |
|
|
|
|
|
|
|
|
|
| |
host-endian-neutral.
Don't assume APInt::getRawData() would hold target-aware endianness nor host-compliant endianness. rawdata[0] holds most lower i64, even on big endian host.
FIXME: Add a testcase for big endian target.
FIXME: Ditto on CompileUnit::addConstantFPValue() ?
llvm-svn: 143194
|
| |
|
|
| |
llvm-svn: 143191
|
| |
|
|
| |
llvm-svn: 143190
|
| |
|
|
|
|
| |
-mtriple=i686-linux. It must be for elf!
llvm-svn: 143189
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
it fixes the dragonegg self-host (it looks like gcc is miscompiled).
Original commit messages:
Eliminate LegalizeOps' LegalizedNodes map and have it just call RAUW
on every node as it legalizes them. This makes it easier to use
hasOneUse() heuristics, since unneeded nodes can be removed from the
DAG earlier.
Make LegalizeOps visit the DAG in an operands-last order. It previously
used operands-first, because LegalizeTypes has to go operands-first, and
LegalizeTypes used to be part of LegalizeOps, but they're now split.
The operands-last order is more natural for several legalization tasks.
For example, it allows lowering code for nodes with floating-point or
vector constants to see those constants directly instead of seeing the
lowered form (often constant-pool loads). This makes some things
somewhat more complicated today, though it ought to allow things to be
simpler in the future. It also fixes some bugs exposed by Legalizing
using RAUW aggressively.
Remove the part of LegalizeOps that attempted to patch up invalid chain
operands on libcalls generated by LegalizeTypes, since it doesn't work
with the new LegalizeOps traversal order. Instead, define what
LegalizeTypes is doing to be correct, and transfer the responsibility
of keeping calls from having overlapping calling sequences into the
scheduler.
Teach the scheduler to model callseq_begin/end pairs as having a
physical register definition/use to prevent calls from having
overlapping calling sequences. This is also somewhat complicated, though
there are ways it might be simplified in the future.
This addresses rdar://9816668, rdar://10043614, rdar://8434668, and others.
Please direct high-level questions about this patch to management.
Delete #if 0 code accidentally left in.
llvm-svn: 143188
|
| |
|
|
|
|
|
| |
tools that read the debug info in the .o files by making the DIE sizes more
consistent.
llvm-svn: 143186
|
| |
|
|
|
|
| |
Fixes rdar://10359193 Indvar LinearFunctionTestReplace assertion
llvm-svn: 143183
|
| |
|
|
| |
llvm-svn: 143179
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on every node as it legalizes them. This makes it easier to use
hasOneUse() heuristics, since unneeded nodes can be removed from the
DAG earlier.
Make LegalizeOps visit the DAG in an operands-last order. It previously
used operands-first, because LegalizeTypes has to go operands-first, and
LegalizeTypes used to be part of LegalizeOps, but they're now split.
The operands-last order is more natural for several legalization tasks.
For example, it allows lowering code for nodes with floating-point or
vector constants to see those constants directly instead of seeing the
lowered form (often constant-pool loads). This makes some things
somewhat more complicated today, though it ought to allow things to be
simpler in the future. It also fixes some bugs exposed by Legalizing
using RAUW aggressively.
Remove the part of LegalizeOps that attempted to patch up invalid chain
operands on libcalls generated by LegalizeTypes, since it doesn't work
with the new LegalizeOps traversal order. Instead, define what
LegalizeTypes is doing to be correct, and transfer the responsibility
of keeping calls from having overlapping calling sequences into the
scheduler.
Teach the scheduler to model callseq_begin/end pairs as having a
physical register definition/use to prevent calls from having
overlapping calling sequences. This is also somewhat complicated, though
there are ways it might be simplified in the future.
This addresses rdar://9816668, rdar://10043614, rdar://8434668, and others.
Please direct high-level questions about this patch to management.
llvm-svn: 143177
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously, if invoked from a CMake build directory, 'llvm-config
--cppflags' and friends would only print a -I flag for the build
directory's header search path, because it would assume that it was
already installed, not recognising its parent directory as being the
build directory. Teach llvm-config about CMake build directories
so that it prints a -I for both the source and build directory's
search paths.
llvm-svn: 143171
|
| |
|
|
|
|
|
|
| |
Just treat it as if the constituent D registers where specified.
rdar://10348896
llvm-svn: 143167
|
| |
|
|
| |
llvm-svn: 143164
|
| |
|
|
| |
llvm-svn: 143163
|
| |
|
|
|
|
| |
previously.
llvm-svn: 143162
|
| |
|
|
|
|
|
| |
Previously, we were only setting the alignment bits on over-aligned
loads and stores.
llvm-svn: 143160
|
| |
|
|
|
|
| |
by Michael Ilseman.
llvm-svn: 143159
|
| |
|
|
| |
llvm-svn: 143158
|
| |
|
|
| |
llvm-svn: 143153
|
| |
|
|
|
|
| |
disassembly support is too MC-engrained to be useful in llvm-objdump.
llvm-svn: 143152
|
| |
|
|
|
|
| |
relocation address, and we don't find a symbol table entry, try section begin addresses as well.
llvm-svn: 143151
|
| |
|
|
| |
llvm-svn: 143149
|
| |
|
|
|
|
| |
- This will require you to manually reconfigure the projects/sample project (by running projects/config/sample/config.status --recheck) if you haven't updated/built since the 1st part of this commit went in.
llvm-svn: 143148
|
| |
|
|
| |
llvm-svn: 143145
|
| |
|
|
|
|
| |
in LLVM tests.
llvm-svn: 143143
|
| |
|
|
| |
llvm-svn: 143142
|
| |
|
|
|
|
| |
- Also, cleanup site.exp files in example tests.
llvm-svn: 143141
|
| |
|
|
|
|
| |
and x86_64 TLV relocations in MachO.
llvm-svn: 143140
|
| |
|
|
| |
llvm-svn: 143135
|
| |
|
|
|
|
| |
comments at top of TypeBasedAliasAnalysis.cpp).
llvm-svn: 143134
|