> Date: Sun, 07 Sep 2008 17:48:17 +0200 > From: Paolo Bonzini <[EMAIL PROTECTED]>
> > 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
