Relax check against commuting XOR and ASHIFTRT in combine.c

Mmmm, I've made a few attempts at filtering according to LP64 and ILP32, but not 
managed to get anything working so far (that is, I've ended up with the test not 
being executed on platforms where it should)....ah, I see now where I've been 
going wrong, patch attached.

The original intent was pretty much to execute the test on everything with the 
appropriate word size, i.e. where a 64-bit comparison would be done in 64 bits 
rather than emulated in 2*32; and for 32-bit where that was not sign-extended to 
64 (or some other such problem). The architectures I wrote in the file, were 
those on which I tested the rtl dump, excluding some archs where you get (neg 
(lt 0 x)) rather than (neg (ge x 0)); but the latter really shouldn't be a 
problem, it should be possible to use a regex matching either form, and then 
drop the target selection.

However, as a quick first step, does adding the ilp32 / lp64 (and keeping the 
architectures list for now) solve the immediate problem? Patch attached, OK for 
trunk?

gcc/testsuite/ChangeLog:

	* gcc.dg/combine_ashiftrt_1.c: require-effective-target LP64
	* gcc.dg/combine_ashiftrt_2.c: require-effective-target ILP32

--Alan

Alan Lawrence <alan.lawrence@arm.com> writes:

> Mmmm, I've made a few attempts at filtering according to LP64 and ILP32,
> but not managed to get anything working so far (that is, I've ended up with
> the test not being executed on platforms where it should)....ah, I see now
> where I've been going wrong, patch attached.
>
> The original intent was pretty much to execute the test on everything with
> the appropriate word size, i.e. where a 64-bit comparison would be done in
> 64 bits rather than emulated in 2*32; and for 32-bit where that was not
> sign-extended to 64 (or some other such problem). The architectures I wrote
> in the file, were those on which I tested the rtl dump, excluding some
> archs where you get (neg (lt 0 x)) rather than (neg (ge x 0)); but the
> latter really shouldn't be a problem, it should be possible to use a regex
> matching either form, and then drop the target selection.
>
> However, as a quick first step, does adding the ilp32 / lp64 (and keeping
> the architectures list for now) solve the immediate problem? Patch
> attached, OK for trunk?

No, as I said this is wrong for biarch targets like sparc and i386.

> gcc/testsuite/ChangeLog:
>
> 	* gcc.dg/combine_ashiftrt_1.c: require-effective-target LP64
> 	* gcc.dg/combine_ashiftrt_2.c: require-effective-target ILP32

Nit: write this as e.g. "Require lp64." 

> diff --git a/gcc/testsuite/gcc.dg/combine_ashiftrt_1.c b/gcc/testsuite/gcc.dg/combine_ashiftrt_1.c
> index 90e64fd..cb669c9 100644
> --- a/gcc/testsuite/gcc.dg/combine_ashiftrt_1.c
> +++ b/gcc/testsuite/gcc.dg/combine_ashiftrt_1.c
> @@ -1,4 +1,5 @@
>  /* { dg-do compile {target sparc64*-*-* aarch64*-*-* x86_64-*-* powerpc64*-*-*} } */

This should be something like 

  { target aarch64*-*-* i?86-*-* powerpc*-*-* sparc*-*-* x86_64-*-* }

E.g. sparc-sun-solaris2.11 with -m64 is lp64, but would be excluded by
your target list.  Keep the list sorted alphabetically and best add an
explanation so others know what those targets have in common.

> +/* { dg-require-effective-target lp64 } */
>  /* { dg-options "-O2 -fdump-rtl-combine-all" } */
>  
>  typedef long long int int64_t;
> diff --git a/gcc/testsuite/gcc.dg/combine_ashiftrt_2.c b/gcc/testsuite/gcc.dg/combine_ashiftrt_2.c
> index fd6827c..6bd6f2f 100644
> --- a/gcc/testsuite/gcc.dg/combine_ashiftrt_2.c
> +++ b/gcc/testsuite/gcc.dg/combine_ashiftrt_2.c
> @@ -1,4 +1,5 @@
>  /* { dg-do compile {target arm*-*-* i?86-*-* powerpc-*-* sparc-*-*} } */

Same here:

  { target arm*-*-* i?86-*-* powerpc*-*-* sparc*-*-* x86_64-*-* }

> +/* { dg-require-effective-target ilp32} */
>  /* { dg-options "-O2 -fdump-rtl-combine-all" } */
>  
>  typedef long int32_t;

	Rainer

Rainer Orth wrote:
>> However, as a quick first step, does adding the ilp32 / lp64 (and keeping
>> the architectures list for now) solve the immediate problem? Patch
>> attached, OK for trunk?
> 
> No, as I said this is wrong for biarch targets like sparc and i386.

When you say no this does not solve the immediate problem, are you saying that 
you are (still) seeing test failures with the require-effective-target patch 
applied? Or is the issue that this would not execute the tests as widely as 
might be possible? In principle I'm quite happy to relax the target patterns, 
although have been having issues with sparc (below)...

Re. "what the architectures have in common" is largely that these are the 
primary/secondary archs on which I've checked the test passes! I can now add 
mips and microblaze to this list, however I'm nervous of dropping the target 
entirely given the very large number of target architectures gcc supports; and 
e.g. IA64 (in ILP32 mode) generates an ashiftrt:DI by 31 places, not 
ashiftrt:SI, which does not match the simplification criteria in combine.c.

> This should be something like 
> 
>   { target aarch64*-*-* i?86-*-* powerpc*-*-* sparc*-*-* x86_64-*-* }
> 
> E.g. sparc-sun-solaris2.11 with -m64 is lp64, but would be excluded by
> your target list.  Keep the list sorted alphabetically and best add an
> explanation so others know what those targets have in common.

So I've built a stage-1 compiler with --target=sparc-sun-solaris2.11, and I find

   * without -m64, my "dg-require-effective-target ilp32" causes the 32-bit test 
to execute, and pass; "dg-require-effective-target lp64" prevents execution of 
the 64-bit test (which would fail) - so all as expected and desired.

   * with -lp64, behaviour is as previous (this is probably expected)

   * with -m64, "dg-require-effective-target ilp32" still causes the test to 
execute (but it fails, as the RTL now has an ashiftrt:DI by 31 places, which 
doesn't meet the simplification criteria in combine.c - this is pretty much as 
expected). "dg-require-effective-target lp64" stops the 64-bit test from 
executing however (despite that it would now pass).

Can you clarify what I should be doing on sparc, therefore?

Thanks for your help!

Alan