patch to fix constant math

[Richard Guenther]

On Fri, Oct 5, 2012 at 4:14 PM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Richard Guenther <richard.guenther@gmail.com> writes:
>> On Fri, Oct 5, 2012 at 3:18 PM, Richard Sandiford
>> <rdsandiford@googlemail.com> wrote:
>>> Richard Sandiford <rdsandiford@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