[Bug rtl-optimization/55611] Operand swapping for commutative operators

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55611

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org

--- Comment #6 from Segher Boessenkool  ---
Mine.

[Bug rtl-optimization/55611] Operand swapping for commutative operators

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55611



--- Comment #5 from Marc Glisse  2013-04-02 12:11:12 
UTC ---

See the discussion at:



http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00692.html



which continues at:



http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00049.html



for why we won't do arbitrary canonicalization.

[Bug rtl-optimization/55611] Operand swapping for commutative operators

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55611



Marc Glisse  changed:



   What|Removed |Added



  Attachment #28931|0   |1

is obsolete||



--- Comment #4 from Marc Glisse  2013-03-12 13:04:28 
UTC ---

Created attachment 29652

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29652

Use tree code to determine the canonical order (2)



With this slight tweak to simplify_associative_operation it now passes

bootstrap+testsuite on x86_64-linux-gnu, both in this order and the reverse

order. I am not sure it is the best way to break the infinite recursion, but it

seems to work.

[Bug rtl-optimization/55611] Operand swapping for commutative operators

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55611



--- Comment #3 from Marc Glisse  2013-03-11 15:14:46 
UTC ---

(In reply to comment #1)

> I also tried the reverse order (just swap x and y in the GET_CODE comparison).

> It got a crazy process during stage3 compiling tree-ssa-address.c (I killed it

> at 40GB).



Seems to be the same problem, at least the call stack looks the same, with IOR

instead of PLUS.

[Bug rtl-optimization/55611] Operand swapping for commutative operators

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55611



--- Comment #2 from Marc Glisse  2013-03-11 14:44:09 
UTC ---

The fortran test that fails is equivalent to the following (use -Ofast -g,

surprisingly it only fails in var tracking)



float f(double*a,double*b){

  double x=a[0]*b[0];

  x+=a[1]*b[1];

  x+=a[2]*b[2];

  x+=a[3]*b[3];

  return x;

}



This happens because of an infinite loop between simplify_associative_operation

and simplify_gen_binary (and a few others) which keeps shuffling the additions

around to try and canonicalize the expression. Some well placed tests whether

GET_CODE(*)==code could probably help, although I am a bit surprised that it

fails so seldom, and only in var-tracking.



I didn't investigate the problem with the reverse order, as stage3 failures (in

middle-end code) are hard to debug...

[Bug rtl-optimization/55611] Operand swapping for commutative operators

[glisse at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55611



--- Comment #1 from Marc Glisse  2012-12-11 22:12:01 
UTC ---

Created attachment 28931

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28931

Use tree code to determine the canonical order



In this patch, I remove the external calls to commutative_operand_precedence,

and I compare GET_CODEs when the current function would say the arguments are

equivalent. This passes bootstrap+testsuite except for one test:

gfortran.dg/pr43229.f90  -O  (internal compiler error)

that I killed when it was 12GB.



I also tried the reverse order (just swap x and y in the GET_CODE comparison).

It got a crazy process during stage3 compiling tree-ssa-address.c (I killed it

at 40GB). Before that, I had tried parts of the testsuite with a

non-bootstrapped compiler, and it seemed to pass just fine.