This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC][PATCH. CSE. rs6000] Update CSE to handle involutory operations


On 11/18/2017 10:47 AM, Peter Bergner wrote:
> On 11/18/17 12:16 AM, Jeff Law wrote:
>> You might wander a bit and see if/how cse handles other similar
>> circumstances.  For example (not (not (x))  (neg (neg x)) and (bswap
>> (bswap (x))
> 
> I actually tried examples like that to see what CSE would do, but I
> could never come up with a test case, where those would survive until
> CSE.  I suppose I could try disabling the optimizations that remove
> them before CSE to see what happens, but...
Or alternately use the RTL front-end to pass in hand crafted RTL for
what you want to test and have compilation start with cse1.  You can see
an example of this in testsuite/gcc.dg/rtl/aarch64/71779.c.


> 
> 
> 
>> THe last would seem particularly interesting -- as a hack see if you can
>> generate a bswap instead of vec_select at expansion time, then see if
>> CSE is able to fix it up.  Or perhaps set it as a REG_EQUAL note.
>> Again, it's a hack, but you just want to see if CSE can see the
>> equivalence if it's in a more common form.  Though I'm not sure if BSWAP
>> is handled significantly better than an equivalence VEC_SELECT.
> 
> ...the problem is that CSE only creates equivalences between two
> expressions when one is assigned to the other.  It doesn't seem to
> look deeper into the expressions to try and find other equivalences,
> so even if we see A = (not (not (B))), the only equivalence it makes
> is that one.  We don't get A is equivalent to B.
But IIRC there are simplifications and checks for equivalent forms that
are attached via REG_EQUAL notes.  Though as you say that may all be
irrelevant.  Again, it's been a real long time since I looked at this
code with any regularity.


> 
> 
> Do you have any input on the following hunk, which seems to be an
> independent change to the rest of the patch?
> 
> @@ -2640,7 +2699,7 @@ exp_equiv_p (const_rtx x, const_rtx y, i
>  	    return 1;
> 
>  	  for (i = regno; i < endregno; i++)
> -	    if (REG_IN_TABLE (i) != REG_TICK (i))
> +	    if (REG_IN_TABLE (i) != -1 && REG_IN_TABLE (i) != REG_TICK (i))
>  	      return 0;
My concern here is that Y is supposed to already be in the table.  If Y
is already in the table, then REG_IN_TABLE (i) shouldn't be -1 IIUC.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]