[Beignet] [PATCH v2 1/2] GBE: continue to refine interfering check.

[Zhigang Gong]

On Wed, Sep 23, 2015 at 03:05:18AM +0000, Song, Ruiling wrote:
> 
> 
> > -----Original Message-----
> > From: Zhigang Gong [mailto:zhigang.gong at linux.intel.com]
> > Sent: Wednesday, September 23, 2015 9:44 AM
> > To: Song, Ruiling
> > Cc: Gong, Zhigang; beignet at lists.freedesktop.org
> > Subject: Re: [Beignet] [PATCH v2 1/2] GBE: continue to refine interfering check.
> > 
> > On Wed, Sep 23, 2015 at 02:33:43AM +0000, Song, Ruiling wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Beignet [mailto:beignet-bounces at lists.freedesktop.org] On
> > > > Behalf Of Zhigang Gong
> > > > Sent: Monday, September 7, 2015 8:20 AM
> > > > To: beignet at lists.freedesktop.org
> > > > Cc: Gong, Zhigang
> > > > Subject: [Beignet] [PATCH v2 1/2] GBE: continue to refine interfering check.
> > > >
> > > > More aggresive interfering check, even if both registers are in
> > > > Livein set or Liveout set, they are still possible not interfering to each other.
> > > >
> > > > v2:
> > > > Liveout interfering check need to take care those BBs which has only
> > > > one register defined.
> > > >
> > > > For example:
> > > >
> > > > BBn:
> > > >   ...
> > > >   MOV %r1, %src
> > > >   ...
> > > >
> > > > Both %r1 and %r2 are in the BBn's liveout set, but %r2 is not
> > > > defined or used in BBn. The previous implementation ignore this BB
> > > > which is incorrect. As %r1 was modified to a different value, it
> > > > means %r1 could not be replaced with %r2 in this case.
> > > I thought of another one: (r0, r1 contain different values)
> > > BB0:
> > >   def r0
> > >
> > > BB1:
> > >   def r1
> > >   use r1
> > >   use r0
> > >
> > > How could the algorithm deal with it?
> > If r1 is a local value in BB1, then it is just ignored in these analysis including DAG
> > and liveness. Don't worry about the correctness of this case, as in
> > gen_reg_allocation we will calculate correct interval for it.
> 
> r1 was only defined and used in BB1. 
> Ignored? the interfere() would return false if I call interfere() with r0 and r1 as arguments. But it should return true, as their live-ranges interfere.

All of the local values have been ignored in DAG and liveness analysis. 
You can check DAG analysis and liveness analysis function or try to dump
liveness information to check. This is not a real problem, as local registers
will be handled correctly in register allocation stage.

> 
> > If r1 is not a local value of BB1, then it's either in live in of liveout set of BB1.
> > Either case, this algorithm could deal it correctly.
> > 
> > > And looks like the algorithm is converting the "live-range
> > > interference problem" into "checking the interference in live-In, live-Out set".
> > > Any paper talking on this method?
> > Actually, most of the paper just talk about to use liveness and DAg information
> > to check interference between the phi and phi copy values to determin whether
> > to coalesce. Not too much details. I just use our liveness information and DAG to
> > do the job.
> > 
> > >
> > > And for same BB interference (r0, r1 defined and used in same BB), although
> > we don't need to support it yet, I think if we can put an assert, it would be better.
> > Could you describe more detail of this case? local variable or not local variable?
> > Are they in live in set or live out set?
> Not in liveout or livein set. They are only defined and used in same Basic Block. But there live-range interfere.
Local variables are irrelevant to this optimization, please check my comment above.

Thanks,
Zhigang Gong.

> 
> > 
> > Thanks for the comments,
> > Zhigang Gong.
> > 
> > >
> > > Thanks!
> > > Ruiling
> > >
> > > _______________________________________________
> > > Beignet mailing list
> > > Beignet at lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/beignet