This is an archive of the discontinued LLVM Phabricator instance.

[AggressiveAntiDepBreaker] Don't change aliased registers of liveins to alive in StartBlock
Needs ReviewPublic

Authored by cycheng on Jun 3 2016, 1:17 AM.

Details

Summary

Current AADB will set aliased registers of liveins to alive in StartBlock, but this is unreasonable, because we will lose rename chances for any rename-able registers of liveins if any of their aliased registers are not be defined.

To correct this, in StartBlock, we only change livein registers to alive, but not include their alias registers.

I've tested the patch on PowerPC, bootstrap test, spec2006 test, llvm test, all result are correct.

Diff Detail

Event Timeline

cycheng updated this revision to Diff 59493.Jun 3 2016, 1:17 AM
cycheng retitled this revision from to [AggressiveAntiDepBreaker] Don't change aliased registers of liveins to alive in StartBlock.
cycheng updated this object.
cycheng added a subscriber: llvm-commits.
cycheng updated this revision to Diff 59656.Jun 4 2016, 8:38 PM

Fix test case to create correct live-in registers for next.bb that can demonstrate the issue.

hfinkel added inline comments.Jun 7 2016, 2:44 PM
lib/CodeGen/AggressiveAntiDepBreaker.cpp
153

Can you please add a comment here:

// We only need to consider the live-out registers themselves, not all aliases, because...

[Discussion in mail]

Nemanja:
Take basic block BB1 and its successor BB2. If there is a definition of register R in BB1 and R is live-in for BB2, then it's OK to rename definitions/uses of R's aliases in BB1. Of course, it is not OK to rename R (the physical register) in BB1. Or am I misreading this?

CY:
Yes, we can rename R's aliases in BB1, my point is: in StartBlock, we only need to set R to live, but not its aliases, so, the question becomes: is my point correct?

Using your case, the incorrect scenario will be:

R's aliases are defined in BB1, and
these define are implicit used in BB2 through R, and
these define are renamed in BB1

So, assume r is an alias of R, then:

BB1:
  def r (last def) <= can we rename this? No, because its alias 'R' is group 0
  def R (last def, group = 0)

BB2:
  live-ins: R
  use R

So, current AADB guards for us that incorrect scenario is not going to happen.

cycheng added a comment.EditedJun 14 2016, 3:17 AM

[Discussion in mail]

Hal:
I think the real question here is, can you have:

BB1:
  def r
  use r

BB2:
  live-ins: R
  use R

or something along those lines? If so, does this work correctly?

CY:
Case1 is work, but Case2 should also work.

Assume r is super register of R.

Case1:

BB1:
  def R => def: R=g0 (Now, R is dead, i.e. enter into new life cycle)
  use R => use: R=g0 (because R is live)
  def r => def: r=gM -> g0 (via R)
  use r => use: g0->gM (last use)

BB2:
  live-ins: R
  use R

Case2:

BB1:
ln1  def r => def: r=gN->gN+1 (via R) (Can be renamed.)
ln2  use r => use: g0->gN (last use) R->gN+1 (last use)
ln3
ln4  def R => def: R=gM (Can be renamed.)
ln5  use R => use: R=g0->gM (last use)
ln6
ln7  def R => def: R=g0 (Now, R is dead, i.e. enter into new life cycle, also update aliases' live-info, so aliases are dead)
ln8  use R => use: R=g0 (because R is live, and init group is 0)

BB2:
  live-ins: R
  use R

I think if BB2 only uses R, then it is fine to rename r in BB1, if BB2 uses r, then r should be one of the live-ins.

cycheng updated this revision to Diff 61511.Jun 22 2016, 12:31 AM

Add explanation in StartBlock to address Hal's review comment.

Hello everyone, any comments on this patch?