| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When trying to fix SGPR live ranges, skip defs that are
killed in the same block as the def. I don't think
we need to worry about these cases as long as the
live ranges of the SGPRs in dominating blocks are
correct.
This reduces the number of elements the second
loop over the function needs to look at, and makes
it generally easier to understand. The second loop
also only considers if the live range is live
in to a block, which logically means it
must have been live out from another.
llvm-svn: 245150
|
| |
|
|
|
|
|
| |
This is simple but won't work if/when this pass
is moved to be post-SSA.
llvm-svn: 245134
|
| |
|
|
|
|
|
|
|
| |
Does not mark SlotIndexes as reserved, although I think
that might be OK.
LiveVariables still need to be handled.
llvm-svn: 245133
|
| |
|
|
|
|
|
| |
These shouldn't ever be null. The number of successors
was already asserted to be 2.
llvm-svn: 245132
|
| |
|
|
|
|
|
|
|
|
|
| |
True branch instructions do behave as expected with liveness.
Avoid the phrasing "branch decision is based on a value in an SGPR"
because this could be misleading. A VALU compare instruction's
result is still based on an SGPR, even though that condition
may be divergent.
llvm-svn: 245131
|
| |
|
|
| |
llvm-svn: 244402
|
|
|
llvm-svn: 239657
|