| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
propagating one of the values it simplified to a constant across
a myriad of instructions. Notably, ptrtoint instructions when we had
a constant pointer (say, 0) didn't propagate that, blocking a massive
number of down-stream optimizations.
This was uncovered when investigating why we fail to inline and delete
the boilerplate in:
void f() {
std::vector<int> v;
v.push_back(1);
}
It turns out most of the efforts I've made thus far to improve the
analysis weren't making it far purely because of this. After this is
fixed, the store-to-load forwarding patch enables LLVM to optimize the
above to an empty function. We still can't nuke a second push_back, but
for different reasons.
There is a very real chance this will cause somewhat noticable changes
in inlining behavior, so please let me know if you see regressions (or
improvements!) because of this patch.
llvm-svn: 171196
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
how to propagate constants through insert and extract value
instructions.
With the recent improvements to instsimplify, this allows inline cost
analysis to constant fold through intrinsic functions, including notably
the with.overflow intrinsic math routines which often show up inside of
STL abstractions. This is yet another piece in the puzzle of breaking
down the code for:
void f() {
std::vector<int> v;
v.push_back(1);
}
But it still isn't enough. There are a pile of bugs in inline cost still
blocking this.
llvm-svn: 171195
|
|
|
|
|
|
|
|
| |
constant folding calls. Add the initial tests for this which show that
now instsimplify can simplify blindingly obvious code patterns expressed
with both intrinsics and library calls.
llvm-svn: 171194
|
|
|
|
|
|
|
|
|
|
| |
are nice and decomposed so that we can simplify synthesized calls as
easily as actually call instructions. The internal utility still has the
same behavior, it just now operates on a more generic interface so that
I can extend the set of call simplifications that instsimplify knows
about.
llvm-svn: 171189
|
|
|
|
| |
llvm-svn: 171183
|
|
|
|
| |
llvm-svn: 171180
|
|
|
|
| |
llvm-svn: 171179
|
|
|
|
|
|
| |
optimizations. The old test cases still cover all of these lowering/optimizations. The single change that we have is that now anyext does not need to zero a register, because it does not use the exact code path as the zero_extend.
llvm-svn: 171178
|
|
|
|
| |
llvm-svn: 171172
|
|
|
|
| |
llvm-svn: 171171
|
|
|
|
|
|
| |
lowering function.
llvm-svn: 171170
|
|
|
|
| |
llvm-svn: 171166
|
|
|
|
|
|
| |
getAnalysisUsage implementations.
llvm-svn: 171157
|
|
|
|
|
|
| |
it describes one of 'interesting' allocas. Assume that allocas can go through casts and phi-nodes before apperaring as llvm.lifetime arguments
llvm-svn: 171153
|
|
|
|
|
|
|
|
|
|
| |
register. In most cases we actually compare or select YMM-sized registers
and mixing the two types creates horrible code. This commit optimizes
some of the transition sequences.
PR14657.
llvm-svn: 171148
|
|
|
|
|
|
|
|
|
|
| |
lowering hook.
The vector truncs were scalarized during LegalizeVectorOps, later vectorized again by some DAGCombine optimization
and finally, lowered by a dagcombing optimization. Now, they are properly lowered during LegalizeVectorOps.
No new testcase because the original testcases still work.
llvm-svn: 171146
|
|
|
|
| |
llvm-svn: 171143
|
|
|
|
|
|
|
|
| |
are before or after different runs of DAGCo, with the CombineLevel enum.
Also, added a new API for checking if we are running before or after the LegalizeVectorOps phase.
llvm-svn: 171142
|
|
|
|
|
|
| |
defm to start with #NAME. This makes instruction names more searchable again.
llvm-svn: 171141
|
|
|
|
| |
llvm-svn: 171140
|
|
|
|
|
|
| |
are currently used by code generation.
llvm-svn: 171137
|
|
|
|
| |
llvm-svn: 171136
|
|
|
|
|
|
| |
per compile unit/skeleton compile unit. Update tests accordingly.
llvm-svn: 171133
|
|
|
|
| |
llvm-svn: 171130
|
|
|
|
|
|
| |
instructions. Shouldn't change any functionality since they don't have patterns to select them.
llvm-svn: 171128
|
|
|
|
|
|
|
|
| |
information doesn't return an addend for Rel relocations. Go ahead
and use this information to fix relocation handling inside dwarfdump
for 32-bit ELF REL.
llvm-svn: 171126
|
|
|
|
|
|
|
|
| |
even if the read objects are unidentified.
PR14719.
llvm-svn: 171124
|
|
|
|
|
|
| |
reversed. Memory form writes memory, but was marked as MRMSrcMem.
llvm-svn: 171123
|
|
|
|
| |
llvm-svn: 171122
|
|
|
|
|
|
| |
side effects.
llvm-svn: 171121
|
|
|
|
| |
llvm-svn: 171120
|
|
|
|
|
|
|
| |
such as by a compiler warning, a check in clang -fsanitizer=undefined, being
optimized to unreachable, or a combination of the above. PR14722.
llvm-svn: 171119
|
|
|
|
|
|
| |
really emitted by the backend, but it reduces the number of instructions in the output files with unmodelled side effects to make auditing easier.
llvm-svn: 171118
|
|
|
|
|
|
| |
instruction didn't have a pattern. This was leftover from when tablegen used to complain if things were already inferred from patterns.
llvm-svn: 171117
|
|
|
|
|
|
| |
the iteration step is -1
llvm-svn: 171114
|
|
|
|
|
|
|
| |
Origin alignment is as high as the alignment of the corresponding application
location, but never less than 4.
llvm-svn: 171110
|
|
|
|
| |
llvm-svn: 171109
|
|
|
|
| |
llvm-svn: 171103
|
|
|
|
| |
llvm-svn: 171102
|
|
|
|
| |
llvm-svn: 171097
|
|
|
|
| |
llvm-svn: 171096
|
|
|
|
| |
llvm-svn: 171095
|
|
|
|
| |
llvm-svn: 171093
|
|
|
|
|
|
| |
definitions for a bunch of SSE2 integer arithmetic instructions.
llvm-svn: 171092
|
|
|
|
| |
llvm-svn: 171091
|
|
|
|
|
|
| |
definitions for PAND/POR/PXOR/PANDN
llvm-svn: 171087
|
|
|
|
| |
llvm-svn: 171086
|
|
|
|
| |
llvm-svn: 171085
|
|
|
|
| |
llvm-svn: 171082
|
|
|
|
|
|
| |
it shouldn't require alignment...
llvm-svn: 171081
|