On Fri, Oct 5, 2012 at 4:14 PM, Richard Sandiford <rdsandif...@googlemail.com> wrote: > Richard Guenther <richard.guent...@gmail.com> writes: >> On Fri, Oct 5, 2012 at 3:18 PM, Richard Sandiford >> <rdsandif...@googlemail.com> wrote: >>> Richard Sandiford <rdsandif...@googlemail.com> writes: >>>>>>> How is CONST_WIDE_INT variable size? >>>>>> >>>>>> It's just the usual trailing variable-length array thing. >>>>> >>>>> Good. Do you get rid of CONST_DOUBLE (for integers) at the same time? >>>> >>>> Yeah. I initially thought it might be OK to keep them and have >>>> CONST_INT, integer CONST_DOUBLEs and CONST_WIDE_INT alongside >>>> each other. (The way the patch is structured means that the >>>> choice of whether to keep integer CONST_DOUBLEs can be changed >>>> very easily.) But Kenny convinced me it was a bad idea. >>> >>> Sorry to follow up on myself, but to clarify: I was talking about >>> converted targets here. (As in, I originally thought even converted >>> targets could continue to use integer CONST_DOUBLEs.) >>> >>> Unconverted targets continue to use CONST_DOUBLE. >> >> Why is it that not all targets are "converted"? What's the difficulty >> with that? >> I really do not like partially transitioning there. > > The problem is that CONST_DOUBLE as it exists today has two meanings: > a floating-point meaning and an integer meaning. Ports that handle > CONST_DOUBLEs are aware of this and expect the two things to have > the same rtx code. Whereas in a converted port, the two things > have different rtx codes, and the integers have a different > representation from the current low/high pair. > > So to take the first hit in config/alpha/alpha.c, > namely alpha_rtx_costs: > > case CONST_DOUBLE: > if (x == CONST0_RTX (mode)) > *total = 0; > else if ((outer_code == PLUS && add_operand (x, VOIDmode)) > || (outer_code == AND && and_operand (x, VOIDmode))) > *total = 0; > else if (add_operand (x, VOIDmode) || and_operand (x, VOIDmode)) > *total = 2; > else > *total = COSTS_N_INSNS (2); > return true; > > What could the patch do to make this work without modification? > The middle two cases are for integers, but the first and last > presumably apply to both integers and floats.
I didn't say it does not require changes, just that the transition should be finished. Some ports have little CONST_DOUBLE uses (which is what I am grepping for), and if the max-wide-int-size matches that of the current CONST_DOUBLE there is little chance for code generation differences (in fact there should be none, correct?). In the current patch no target is converted (maybe that's just going to be 5/n?), I'd like to see at least one commonly tested target converted and if we don't convert all targets another commonly tested target to stay unconverted (just check gcc-testresults for which pair of targets that would work). Definitely at the end of stage3 we should have zero unconverted targets (but I doubt converting them is a huge task - I have converted the VECTOR_CST representation as well and we've had the location + BLOCK merge and other changes affecting all targets). Richard. > Richard
