On Wed, Sep 23, 2015 at 03:05:18AM +0000, Song, Ruiling wrote: > > > > -----Original Message----- > > From: Zhigang Gong [mailto:zhigang.g...@linux.intel.com] > > Sent: Wednesday, September 23, 2015 9:44 AM > > To: Song, Ruiling > > Cc: Gong, Zhigang; beignet@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-boun...@lists.freedesktop.org] On > > > > Behalf Of Zhigang Gong > > > > Sent: Monday, September 7, 2015 8:20 AM > > > > To: beignet@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@lists.freedesktop.org > > > http://lists.freedesktop.org/mailman/listinfo/beignet _______________________________________________ Beignet mailing list Beignet@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/beignet
