The vast majority of virtual register definitions don't need an entry
in the DAG builder's VRegDefs set.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151136 91177308-0d34-0410-b5e6-96231b3b80d8
Affect on SD scheduling and postRA scheduling:
Printing the DAG will display the nodes in top-down topological order.
This matches the order within the MBB and makes my life much easier in general.
Affect on misched:
We don't need to track virtual register uses at all. This is awesome.
I also intend to rely on the SUnit ID as a topo-sort index. So if A < B then we cannot have an edge B -> A.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151135 91177308-0d34-0410-b5e6-96231b3b80d8
the dominance once the dominates method is fixed and why we can use the builder's
insertion point.
Fixes pr12048.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151125 91177308-0d34-0410-b5e6-96231b3b80d8
This makes RAFast 4% faster, and it gets rid of the dodgy DenseMap
iteration.
This also revealed that RAFast would sometimes dereference DenseMap
iterators after erasing other elements from the map. That does seem to
work in the current DenseMap implementation, but SparseSet doesn't allow
it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151111 91177308-0d34-0410-b5e6-96231b3b80d8
Even if a call instruction has %SP<imp-def> operands, it doesn't change
the value of the stack pointer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151104 91177308-0d34-0410-b5e6-96231b3b80d8
bundles. This method takes a bundle start and an MI being bundled, and makes
the intervals for the MI's operands appear to start/end on the bundle start.
Also fixes some minor cosmetic issues (whitespace, naming convention) in the
HMEditor code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151099 91177308-0d34-0410-b5e6-96231b3b80d8
they'll be simple enough to simulate, and to reduce the chance we'll encounter
equal but different simple pointer constants.
This removes the symptoms from PR11352 but is not a full fix. A proper fix would
either require a guarantee that two constant objects we simulate are folded
when equal, or a different way of handling equal pointers (ie., trying a
constantexpr icmp on them to see whether we know they're equal or non-equal or
unsure).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151093 91177308-0d34-0410-b5e6-96231b3b80d8
This transformation is not safe in some pathological cases (signed icmp of pointers should be an
extremely rare thing, but it's valid IR!). Add an explanatory comment.
Kudos to Duncan for pointing out this edge case (and not giving up explaining it until I finally got it).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151055 91177308-0d34-0410-b5e6-96231b3b80d8
using a DenseMap and Talin's new GeneralHash, avoiding the need for a
temporary std::vector on every lookup.
Patch by Meador Inge!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151049 91177308-0d34-0410-b5e6-96231b3b80d8
They're private static methods but we can just make them static
functions in the implementation. It makes the implementations a touch
more wordy, but takes another chunk out of the header file.
Also, take the opportunity to switch the names to the new coding
conventions.
No functionality changed here.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151047 91177308-0d34-0410-b5e6-96231b3b80d8
Passes after RegAlloc should be able to rely on MRI->getNumVirtRegs() == 0.
This makes sharing code for pre/postRA passes more robust.
Now, to check if a pass is running before the RA pipeline begins, use MRI->isSSA().
To check if a pass is running after the RA pipeline ends, use !MRI->getNumVirtRegs().
PEI resets virtual regs when it's done scavenging.
PTX will either have to provide its own PEI pass or assign physregs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151032 91177308-0d34-0410-b5e6-96231b3b80d8
construction. Simplify its interface, implementation, and users
accordingly as there is no longer an 'uninitialized' state to check for.
Also, fixes a bug lurking in the interface as there was one method that
didn't correctly check for initialization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151024 91177308-0d34-0410-b5e6-96231b3b80d8
know where users will be added. Because of this, it cannot use
Builder.GetInsertPoint at all.
This patch
* removes the FIXME about adding the assert.
* adds a comment explaining hy we don't have one.
* removes a broken logic that only works for some callers and is not needed
since r150884.
* adds an assert to caller that would have caught the bug fixed by r150884.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151015 91177308-0d34-0410-b5e6-96231b3b80d8
ecx = mov eax
al = mov ch
The second copy is not a nop because the sub-indices of ecx,ch is not the
same of that of eax/al.
Re-enabled machine-cp.
PR11940
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@151002 91177308-0d34-0410-b5e6-96231b3b80d8
- Ignore pointer casts.
- Also expand GEPs that aren't constantexprs when they have one use or only constant indices.
- We now compile "&foo[i] - &foo[j]" into "i - j".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150961 91177308-0d34-0410-b5e6-96231b3b80d8
Teach TargetSelectionDAG about lengthening loads for vector types and set v4i8 as legal. Allow FP_TO_UINT for v4i16 from v4i32.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150956 91177308-0d34-0410-b5e6-96231b3b80d8
the cast. If we do, we can end up with
inst1
--------------- < Insertion point
dbg inst
new inst
instead of the desired
inst1
new inst
--------------- < Insertion point
dbg inst
Another option would be for InsertNoopCastOfTo (or its callers) to move the
insertion point and we would end up with
inst1
dbg inst
new inst
--------------- < Insertion point
but that complicates the callers. This fixes PR12018 (and firefox's build).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150884 91177308-0d34-0410-b5e6-96231b3b80d8
MRI keeps track of which physregs have been used. Make sure it gets
updated with all the regmask-clobbered registers.
Delete the closePhysRegsUsed() function which isn't necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150830 91177308-0d34-0410-b5e6-96231b3b80d8
metadata may still unwind, but only in ways that the ARC
optimizer doesn't need to consider. This permits more
aggressive optimization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150829 91177308-0d34-0410-b5e6-96231b3b80d8
any changes.
Internally this adds a private inner class HMEditor, to LiveIntervals. HMEditor provides
an API for updating live intervals when code is moved or bundled.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150826 91177308-0d34-0410-b5e6-96231b3b80d8
actually work, at least as described. LLVM Metadata is not
intended to suppress LLVM IR rules, as it can be stripped at
any time.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150821 91177308-0d34-0410-b5e6-96231b3b80d8
This caused miscompilations on out-of-tree targets, and possibly i386 as
well.
I'll find some other way of hoisting %rip-relative loads from loops
containing calls.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150816 91177308-0d34-0410-b5e6-96231b3b80d8
Fix the type of eh_frame on Solaris so that Sun ld doesn't fail to combine them (thus making it impossible for the unwind library to find them and breaking exceptions).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150814 91177308-0d34-0410-b5e6-96231b3b80d8
Thanks to Anton, Duncan and Rafael for helping me track this down.
Pointy hat to Rafael for introducing the bug in the first place.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150811 91177308-0d34-0410-b5e6-96231b3b80d8
useful to represent a variable that is const in the source but can't be constant
in the IR because of a non-trivial constructor. If globalopt evaluates the
constructor, and there was an invariant.start with no matching invariant.end
possible, it will mark the global constant afterwards.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150794 91177308-0d34-0410-b5e6-96231b3b80d8
