Re: PR37363: PR36090 and PR36182 all over again

[Paolo Bonzini <bonzini at gnu dot org>]

> Only with a LEGITIMATE_CONSTANT_P catching it...

Of course.

> So, can we agree on some or all of:
> 
> 1. This (PR37363/PR36182) and PR36090 (in both ports) and
>    whatever other port will be affected should be solved by a
>    stricter LEGITIMATE_CONSTANT_P check, and where
>    canonicalization is undefined (and a new definition can't get
>    consensus agreed upon), the port has to check itself for
>    whatever RTL expression it accepts.
> 
> 2. Change the LEGITIMATE_CONSTANT_P documentation.
> 
> 3. Change the default of LEGITIMATE_CONSTANT_P to a helper
>    function, maybe trivial_constant_expression_p above.

Agreed, but I don't see t_c_e_p in GCC sources (if you meant my function
using the predicate, it cannot work because the predicate might in turn
call LEGITIMATE_CONSTANT_P).  It could be

  if (GET_CODE (x) != CONST)
    return true;

  x = XEXP (x, 0);
  return GET_CODE (x) == PLUS && GET_CODE (XEXP (x, 1)) == CONST_INT
         && (GET_CODE (XEXP (x, 0)) == SYMBOL_REF
             || GET_CODE (XEXP (x, 0)) == LABEL_REF);

(i.e. the test in cse.c) or something like that.

Would you change simplify-rtx.c to test LEGITIMATE_CONSTANT_P before
wrapping something with a CONST?

Alternatively, I wouldn't mind see rs6000 use unspecs for GOT/TOC
offsets as other ports do; this would allow removing the optimization in
simplify_plus_minus, which would fix CRIS too (because I'm worried that
other targets might be affected, not just CRIS).  Of course, if that
gives known pessimizations on rs6000 it would not be a good thing to do,
and probably no one would volunteer to do that change anyway, so...

Paolo