| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
| |
This avoids a gazillion StringMap and dynamic_cast calls, making
TableGen run 3x faster.
llvm-svn: 148091
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
overly conservative. It was concerned about cases where it would prohibit
folding simple [r, c] addressing modes. e.g.
ldr r0, [r2]
ldr r1, [r2, #4]
=>
ldr r0, [r2], #4
ldr r1, [r2]
Change the logic to look for such cases which allows it to form indexed memory
ops more aggressively.
rdar://10674430
llvm-svn: 148086
|
| |
|
|
| |
llvm-svn: 148077
|
| |
|
|
|
|
|
|
| |
the optimizer doesn't eliminate objc_retainBlock calls which are needed
for their side effect of copying blocks onto the heap.
This implements rdar://10361249.
llvm-svn: 148076
|
| |
|
|
| |
llvm-svn: 148067
|
| |
|
|
| |
llvm-svn: 148065
|
| |
|
|
|
|
|
| |
The registers are placed into the saved registers list in the reverse order,
which is why the original loop was written to loop backwards.
llvm-svn: 148064
|
| |
|
|
|
|
|
|
| |
Promote for those operations.
Sorry, no test case yet
llvm-svn: 148050
|
| |
|
|
|
|
|
| |
lc: X86ISelLowering.cpp:6480: llvm::SDValue llvm::X86TargetLowering::LowerVECTOR_SHUFFLE(llvm::SDValue, llvm::SelectionDAG&) const: Assertion `V1.getOpcode() != ISD::UNDEF&& "Op 1 of shuffle should not be undef"' failed.
Added a test.
llvm-svn: 148044
|
| |
|
|
|
|
|
|
|
|
|
| |
killed registers are needed below the insertion point, then unset the kill
marker.
Sorry I'm not able to find a reduced test case.
rdar://10660944
llvm-svn: 148043
|
| |
|
|
|
|
|
| |
This patch uses tcb_spare field in the tcb structure to store info.
Patch by Jyun-Yan You.
llvm-svn: 148041
|
| |
|
|
|
|
|
| |
Uses the pvArbitrary slot of the TIB, which is reserved for applications. We
only support frames with a static size.
llvm-svn: 148040
|
| |
|
|
| |
llvm-svn: 148033
|
| |
|
|
|
|
| |
We are using one parser to parse att as well as intel style syntax.
llvm-svn: 148032
|
| |
|
|
| |
llvm-svn: 148031
|
| |
|
|
|
|
|
|
|
| |
Restore the (obviously wrong) behavior from before r147938 without relying on
undefined behavior. Add a fat FIXME note.
This should fix nightly tester failures.
llvm-svn: 148030
|
| |
|
|
|
|
|
|
| |
is on the boundary of two 128-bit vectors.
The attached testcase was stuck in an endless loop.
llvm-svn: 148027
|
| |
|
|
|
|
| |
more set bits set than 31 or 63.
llvm-svn: 148024
|
| |
|
|
|
|
| |
In att style asm syntax memory operand size is derived from suffix attached with mnemonic. In intel style asm syntax it is part of memory operand hence predicate method check is required to select appropriate instruction.
llvm-svn: 148006
|
| |
|
|
|
|
|
| |
need to make a deep copy of each of the std::maps. Use a std::map of the
std::map instead. This improves the compile time of sqlite3 by ~2%.
llvm-svn: 148003
|
| |
|
|
|
|
| |
This is a work in progress.
llvm-svn: 148002
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
same pattern. We already had this pattern is a few places, but others
tried to make a rough approximation of an actual DAG structure. As not
everywhere went to this trouble, nothing could rely on this being done.
In fact, I've checked all references to these node Ids, and the ones
that are using the topo-sort properties are actually satisfied with
a strict-weak-ordering. The requirement appears to be that Use >= Def.
I've added a big blurb of comments to this bit of the transform to
clarify why the order is so important for the next reader of the code.
I'm starting with this change as it is very small, and trivially
reverted if something breaks or the >= above really does need to be >.
If that proves the case, we can hide the problem by reverting this
patch, but the problem exists elsewhere as well, and so a more
comprehensive solution will be needed.
llvm-svn: 148001
|
| |
|
|
| |
llvm-svn: 147980
|
| |
|
|
| |
llvm-svn: 147979
|
| |
|
|
|
|
| |
This appears to improve sqlite3's compile time by ~2%.
llvm-svn: 147978
|
| |
|
|
|
|
| |
This helper method is too simplistic for RAGreedy.
llvm-svn: 147976
|
| |
|
|
| |
llvm-svn: 147975
|
| |
|
|
|
|
| |
No functional change.
llvm-svn: 147972
|
| |
|
|
|
|
| |
doesn't abuse the semantics of linker_private. We don't really want to merge any string constant with a weak_odr global.
llvm-svn: 147971
|
| |
|
|
| |
llvm-svn: 147966
|
| |
|
|
| |
llvm-svn: 147965
|
| |
|
|
|
|
|
|
|
|
| |
are used.
When we load the v12i32 type, the GenWidenVectorLoads method generates two loads: v8i32 and v4i32
and attempts to use CONCAT_VECTORS to join them. In this fix I concat undef values to widen
the smaller value. The test "widen_load-2.ll" also exposes this bug on AVX.
llvm-svn: 147964
|
| |
|
|
|
|
|
|
| |
This uses TLS slot 90, which actually belongs to JavaScriptCore. We only support
frames with static size
Patch by Brian Anderson.
llvm-svn: 147960
|
| |
|
|
|
|
| |
Patch by Brian Anderson.
llvm-svn: 147958
|
| |
|
|
|
|
|
|
|
| |
hoped this would revive one of the llvm-gcc selfhost build bots, but it
didn't so it doesn't appear that my transform is the culprit.
If anyone else is seeing failures, please let me know!
llvm-svn: 147957
|
| |
|
|
|
|
|
|
| |
This is a comparison of two addresses, and GCC does the comparison unsigned.
Patch by Brian Anderson.
llvm-svn: 147954
|
| |
|
|
|
|
| |
don't instrument the function at all on x86_32 if it has a large asm blob
llvm-svn: 147953
|
| |
|
|
|
|
| |
Patch by Brian Anderson.
llvm-svn: 147952
|
| |
|
|
|
|
|
| |
directives was in the wrong place and getting triggered incorectly with a
cpp .file directive. This change fixes that and adds a test case.
llvm-svn: 147951
|
| |
|
|
| |
llvm-svn: 147949
|
| |
|
|
|
|
| |
zero untouched elements. Use INSERT_VECTOR_ELT instead.
llvm-svn: 147948
|
| |
|
|
|
|
|
| |
are invalid). Fixes a crash on array1.C from the GCC testsuite when
compiled with dragonegg.
llvm-svn: 147946
|
| |
|
|
|
|
|
|
| |
strange build bot failures that look like a miscompile into an infloop.
I'll investigate this tomorrow, but I'd both like to know whether my
patch is the culprit, and get the bots back to green.
llvm-svn: 147945
|
| |
|
|
|
|
| |
lots of lines of code. No functionality changed.
llvm-svn: 147942
|
| |
|
|
|
|
| |
SRL-rooted code.
llvm-svn: 147941
|
| |
|
|
|
|
|
| |
factor the differences that were hiding in one of them into its other
caller, the SRL handling code. No change in behavior.
llvm-svn: 147940
|
| |
|
|
|
|
|
|
|
|
| |
mask+shift pairs at the beginning of the ISD::AND case block, and then
hoist the final pattern into a helper function, simplifying and
reflowing it appropriately. This should have no observable behavior
change, but several simplifications fell out of this such as directly
computing the new mask constant, etc.
llvm-svn: 147939
|
| |
|
|
|
|
|
| |
I don't think the compact encoding code is right, but at least is has
defined behavior now.
llvm-svn: 147938
|
| |
|
|
|
|
|
|
| |
extracts and scaled addressing modes into its own helper function. No
functionality changed here, just hoisting and layout fixes falling out
of that hoisting.
llvm-svn: 147937
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
detect a pattern which can be implemented with a small 'shl' embedded in
the addressing mode scale. This happens in real code as follows:
unsigned x = my_accelerator_table[input >> 11];
Here we have some lookup table that we look into using the high bits of
'input'. Each entity in the table is 4-bytes, which means this
implicitly gets turned into (once lowered out of a GEP):
*(unsigned*)((char*)my_accelerator_table + ((input >> 11) << 2));
The shift right followed by a shift left is canonicalized to a smaller
shift right and masking off the low bits. That hides the shift right
which x86 has an addressing mode designed to support. We now detect
masks of this form, and produce the longer shift right followed by the
proper addressing mode. In addition to saving a (rather large)
instruction, this also reduces stalls in Intel chips on benchmarks I've
measured.
In order for all of this to work, one part of the DAG needs to be
canonicalized *still further* than it currently is. This involves
removing pointless 'trunc' nodes between a zextload and a zext. Without
that, we end up generating spurious masks and hiding the pattern.
llvm-svn: 147936
|