| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
This adds a G_INSERT instruction, which technically makes G_SEQUENCE redundant
(it's equivalent to a G_INSERT into an IMPLICIT_DEF). We'll leave G_SEQUENCE
for now though: it's likely to be far more common as it's a fundamental part of
legalization, so avoiding the mess and bloat of the extra IMPLICIT_DEFs is
probably worthwhile.
llvm-svn: 279306
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: This way they can be re-used by target-specific schedulers.
Reviewers: atrick, MatzeB, kparzysz
Subscribers: kparzysz, llvm-commits, MatzeB
Differential Revision: https://reviews.llvm.org/D23678
llvm-svn: 279305
|
| |
|
|
| |
llvm-svn: 279303
|
| |
|
|
| |
llvm-svn: 279302
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Specifically, this is done near the end of "SimplifyICmpInst" using
computeKnownBits() as the broader solution. There are even vector
tests (yay!) for this in test/Transforms/InstSimplify/compare.ll.
I considered putting an assert here instead of just deleting, but
then we could assert every possible fold in InstSimplify in
InstCombine, so...less is more?
llvm-svn: 279300
|
| |
|
|
|
|
|
|
| |
They can be deleted or replicated, so the cache may become outdated.
They only need to be visited once during frame lowering, so just scan
the function instead.
llvm-svn: 279297
|
| |
|
|
|
|
|
|
|
|
|
| |
was done to hopefully appease MSVC.
As an upside, this also implements the suggestion Sanjoy made in code
review, so two for one! =]
I'll be watching the bots to see if there are still issues.
llvm-svn: 279295
|
| |
|
|
|
|
|
|
|
|
|
|
| |
First, make sure all types involved are represented, rather than being implicit
from the register width.
Second, canonicalize all types to scalar. These operations just act in bits and
don't care about vectors.
Also standardize spelling of Indices in the MachineIRBuilder (NFC here).
llvm-svn: 279294
|
| |
|
|
|
|
| |
This reverts commit bfd62a4b4465dd21811bf615c3b04c30ddb09f7b.
llvm-svn: 279289
|
| |
|
|
|
|
| |
This reverts commit 0fda93481c4231c06b838ef476c0c404c51ff875.
llvm-svn: 279288
|
| |
|
|
| |
llvm-svn: 279287
|
| |
|
|
|
|
|
| |
- Recognize C2_cmpgtui, S2_tstbit_i, and S4_ntstbit_i.
- Avoid creating new-value instructions with both source operands equal.
llvm-svn: 279286
|
| |
|
|
| |
llvm-svn: 279285
|
| |
|
|
| |
llvm-svn: 279282
|
| |
|
|
| |
llvm-svn: 279280
|
| |
|
|
| |
llvm-svn: 279279
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Unsigned addition and subtraction can reuse the instructions created to
legalize large width operations (i.e. both produce and consume a carry flag).
Signed operations and multiplies get a dedicated op-with-overflow instruction.
Once this is produced the two values are combined into a struct register (which
will almost always be merged with a corresponding G_EXTRACT as part of
legalization).
llvm-svn: 279278
|
| |
|
|
|
|
|
|
| |
This reverts commit r279178.
Speculative revert in hope to fix asan crash on arm.
llvm-svn: 279277
|
| |
|
|
|
|
|
|
| |
This reverts commit r279222.
Speculative revert in hope to fix asan crash on arm.
llvm-svn: 279276
|
| |
|
|
| |
llvm-svn: 279275
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Repeated inserts into AliasSetTracker have quadratic behavior - inserting a
pointer into AST is linear, since it requires walking over all "may" alias
sets and running an alias check vs. every pointer in the set.
We can avoid this by tracking the total number of pointers in "may" sets,
and when that number exceeds a threshold, declare the tracker "saturated".
This lumps all pointers into a single "may" set that aliases every other
pointer.
(This is a stop-gap solution until we migrate to MemorySSA)
This fixes PR28832.
Differential Revision: https://reviews.llvm.org/D23432
llvm-svn: 279274
|
| |
|
|
|
|
| |
This doesn't change tests codegen as we already combined to blend+zero which is what we lower VZEXT_MOVL to on SSE41+ targets, but it does put us in a better position when we improve shuffling for optsize.
llvm-svn: 279273
|
| |
|
|
|
|
|
|
|
| |
Ensure that load locked and store conditional instructions are only
packetized with ALU32 instructions.
Patch by Ben Craig.
llvm-svn: 279272
|
| |
|
|
|
|
|
|
|
|
|
| |
The intended transform is:
// Simplify icmp eq (or (ptrtoint P), (ptrtoint Q)), 0
// -> and (icmp eq P, null), (icmp eq Q, null).
P and Q are both pointer types, but may have different types. We need
two calls to getNullValue() to make the icmps.
llvm-svn: 279271
|
| |
|
|
| |
llvm-svn: 279269
|
| |
|
|
|
|
|
|
| |
CGSCC use a WeakVH to track call sites. RAUW a call within a function
can result in that WeakVH getting confused about whether or not the call
site is still around.
llvm-svn: 279268
|
| |
|
|
|
|
| |
Patch by Jyotsna Verma.
llvm-svn: 279267
|
| |
|
|
|
|
| |
constant vectors
llvm-svn: 279266
|
| |
|
|
| |
llvm-svn: 279265
|
| |
|
|
|
|
|
|
|
| |
Of course, we really need to refactor and fix all of the cmp predicates,
but this one is interesting because without it, we later perform an
information-losing transform of icmp (shl 1, Y), C, and we can't recover
the better fold.
llvm-svn: 279263
|
| |
|
|
|
|
| |
and LTO specifc path (NFC)
llvm-svn: 279261
|
| |
|
|
| |
llvm-svn: 279255
|
| |
|
|
| |
llvm-svn: 279254
|
| |
|
|
|
|
| |
Patch by Arnold Schwaighofer.
llvm-svn: 279251
|
| |
|
|
|
|
| |
Patch by Brendon Cahoon.
llvm-svn: 279249
|
| |
|
|
| |
llvm-svn: 279248
|
| |
|
|
| |
llvm-svn: 279247
|
| |
|
|
| |
llvm-svn: 279246
|
| |
|
|
| |
llvm-svn: 279245
|
| |
|
|
| |
llvm-svn: 279244
|
| |
|
|
| |
llvm-svn: 279243
|
| |
|
|
|
|
|
|
|
|
|
|
| |
not bytes.
In addition, the branch instructions will have proper BB destinations, not offsets, like before.
Patch by Vadzim Dambrouski!
Differential Revision: https://reviews.llvm.org/D20162
llvm-svn: 279242
|
| |
|
|
| |
llvm-svn: 279241
|
| |
|
|
|
|
|
|
|
| |
Improved handling of fma, floating point min/max, additional load/store
instructions for floating point types.
Patch by Jyotsna Verma.
llvm-svn: 279239
|
| |
|
|
| |
llvm-svn: 279233
|
| |
|
|
|
|
|
|
| |
solve completely opaque MSVC build errors. It complains about lots of
stuff with this change without givin nearly enough information to even
try to fix.
llvm-svn: 279231
|
| |
|
|
|
|
| |
INSERTPS doesn't fit well with our shuffle mask canonicalization, so we need to attempt both the original mask and the commuted mask to more likely get a match
llvm-svn: 279230
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new version has several advantages:
1) IMSHO it's more readable and neater
2) It handles loads and stores properly
3) It can handle any number of incoming blocks rather than just two. I'll be taking advantage of this in a followup patch.
With this change we can now finally sink load-modify-store idioms such as:
if (a)
return *b += 3;
else
return *b += 4;
=>
%z = load i32, i32* %y
%.sink = select i1 %a, i32 5, i32 7
%b = add i32 %z, %.sink
store i32 %b, i32* %y
ret i32 %b
When this works for switches it'll be even more powerful.
llvm-svn: 279229
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to run methods, both for transform passes and analysis passes.
This also allows the analysis manager to use a different set of extra
arguments from the pass manager where useful. Consider passes over
analysis produced units of IR like SCCs of the call graph or loops.
Passes of this nature will often want to refer to the analysis result
that was used to compute their IR units (the call graph or LoopInfo).
And for transformations, they may want to communicate special update
information to the outer pass manager. With this change, it becomes
possible to have a run method for a loop pass that looks more like:
PreservedAnalyses run(Loop &L, AnalysisManager<Loop, LoopInfo> &AM,
LoopInfo &LI, LoopUpdateRecord &UR);
And to query the analysis manager like:
AM.getResult<MyLoopAnalysis>(L, LI);
This makes accessing the known-available analyses convenient and clear,
and it makes passing customized data structures around easy.
My initial use case is going to be in updating the pass manager layers
when the analysis units of IR change. But there are more use cases here
such as having a layer that lets inner passes signal whether certain
additional passes should be run because of particular simplifications
made. Two desires for this have come up in the past: triggering
additional optimization after successfully unrolling loops, and
triggering additional inlining after collapsing indirect calls to direct
calls.
Despite adding this layer of generic extensibility, the *only* change to
existing, simple usage are for places where we forward declare the
AnalysisManager template. We really shouldn't be doing this because of
the fragility exposed here, but currently it makes coping with the
legacy PM code easier.
Differential Revision: http://reviews.llvm.org/D21462
llvm-svn: 279227
|
| |
|
|
|
|
|
|
| |
The heuristic above this code is incredibly suspect, but disregarding that it mutates the cast opcode so we need to check the *mutated* opcode later to see if we need to emit an AssertSext or AssertZext node.
Fixes PR29041.
llvm-svn: 279223
|