PR37363: PR36090 and PR36182 all over again

[Hans-Peter Nilsson]

> Date: Sun, 07 Sep 2008 17:48:17 +0200
> From: Paolo Bonzini <bonzini@gnu.org>

> > 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

Of course not, as it's a *proposed* new helper function, but
nevertheless exactly as your suggestion. ;)

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

No, because as I mentioned, those CONSTs aren't only meant for
operands.  The change is validate_change'd later, so the new
LEGITIMATE_CONSTANT_P change catches the PR case and all is
good.  (It'd work for a move too, since we're dealing with
actual insns, not forced move expansion trickery.)

> 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).

Affecting not just CRIS is exactly a point I've been trying to
make clear!  But... those other targets would also be covered
with CONST-validizing LEGITIMATE_CONSTANT_P.  (Just an inside
guess, test results from CRIS change not in yet.)

>  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...

*shrug*
With proper UNSPECs for their GOT and TOC expressions, I don't
think they'd suffer.  But, I don't have a horse in that race.

tm.texi change coming up.

brgds, H-P