On 10/05/2012 10:36 AM, Richard Guenther wrote:
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.
i will convert ppc if that is what it takes. david's office is 4 isles
away and mike has a lot of experience on ppc also. (this is unless
richard is willing to do mips one afternoon.) I have done my two
private ports but i understand that that should not count.
Richard
