GCSE problem on a gcc testsuite

[johnc]

Hi all,
  I am facing with a GCSE problem on this GCC
testsuite(gcc/testsuite/gcc.c-torture/execute/pr38819.c),using
GCC-4.4.0:

extern void exit (int);
extern void abort (void);
volatile int a = 1;
volatile int b = 0;
volatile int x = 2;
volatile signed int r = 8;
void __attribute__((noinline))
foo (void)
{
  exit (0);
}
int
main (void)
{
  int si1 = a;
  int si2 = b;
  int i;
  for (i = 0; i < 100; ++i) {
      foo ();
      if (x == 8)
        i++;
      r += i + si1 % si2;
  }
  abort ();
}

  On the mips64 architecture,instruction for si1%si2(that is,div) will
put the result in LO and HI,and thus GCC don't want to do GCSE
optimization on this instruction(see gcc/gcse.c:want_to_gcse_p()).

  But now I am facing with a new instruction which will put the result
in a single register,and thus GCC want to do GCSE on this
instruction.GCC will treat si1%si2 as a loop invariant.So si1%si2 was
moved out of the loop,just before the execution of function foo();as
si2 is equal 0,there occurs a trap which shouldn't have occurred
according to the original semantic.

   I am considering a solution:in a certain basic block,if there
exists a function call rtx(which might exit or even trap in
advance),then we shall not do GCSE optimization on the following rtx
which might trap(see rtlanal.c:may_trap_p()).But it seems the cost is
expensive,and I am not quite sure whether or not it works.

   So,does anyone have any suggestions?
   Thanks in advance.

Re: GCSE problem on a gcc testsuite

[johnc]

  Well,then I am not quite sure about the usage of this testsuite.Most
testsuites seem to be used to test whether or not a kind of
optimization works,and according to your view,this testsuite seems to
be useless.
  So do you think it is proper if we remove this testsuite from the
GCC testsuites?
  Thanks again.

On Wed, Oct 13, 2010 at 3:12 PM, Eric Botcazou  wrote:
>>   But now I am facing with a new instruction which will put the result
>> in a single register,and thus GCC want to do GCSE on this
>> instruction.GCC will treat si1%si2 as a loop invariant.So si1%si2 was
>> moved out of the loop,just before the execution of function foo();as
>> si2 is equal 0,there occurs a trap which shouldn't have occurred
>> according to the original semantic.
>
> This happens for other targets as well, see the audit trail of the PR.
>
>>    I am considering a solution:in a certain basic block,if there
>> exists a function call rtx(which might exit or even trap in
>> advance),then we shall not do GCSE optimization on the following rtx
>> which might trap(see rtlanal.c:may_trap_p()).But it seems the cost is
>> expensive,and I am not quite sure whether or not it works.
>
> Any attempt along these lines would most likely pessimize the common case.
>
> This PR is a pathological case that doesn't come from real life and fixing it
> properly is hard, so I wouldn't bother about it.
>
> --
> Eric Botcazou
>