> 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
