This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: patch to fix constant math -5th patch, rtl


On Fri, May 3, 2013 at 1:49 PM, Kenneth Zadeck <zadeck@naturalbridge.com> wrote:
> On 05/03/2013 07:34 AM, Richard Biener wrote:
>>
>> On Thu, Apr 25, 2013 at 1:18 AM, Kenneth Zadeck
>> <zadeck@naturalbridge.com> wrote:
>>>
>>> On 04/24/2013 11:13 AM, Richard Biener wrote:
>>>>
>>>> On Wed, Apr 24, 2013 at 5:00 PM, Richard Sandiford
>>>> <rdsandiford@googlemail.com>  wrote:
>>>>>
>>>>> Richard Biener<richard.guenther@gmail.com>  writes:
>>>>>>
>>>>>> On Wed, Apr 24, 2013 at 4:29 PM, Richard Sandiford
>>>>>> <rdsandiford@googlemail.com>  wrote:
>>>>>>>
>>>>>>> In other words, one of the reasons wide_int can't be exactly 1:1
>>>>>>> in practice is because it is clearing out these mistakes (GEN_INT
>>>>>>> rather than gen_int_mode) and missing features (non-power-of-2
>>>>>>> widths).
>>>>>>
>>>>>> Note that the argument should be about CONST_WIDE_INT here,
>>>>>> not wide-int.  Indeed CONST_WIDE_INT has the desired feature
>>>>>> and can be properly truncated/extended according to mode at the time
>>>>>> we
>>>>>> build it
>>>>>> via immed_wide_int_cst (w, mode).  I don't see the requirement that
>>>>>> wide-int itself is automagically providing that truncation/extension
>>>>>> (though it is a possibility, one that does not match existing behavior
>>>>>> of
>>>>>> HWI for CONST_INT or double-int for CONST_DOUBLE).
>>>>>
>>>>> I agree it doesn't match the existing behaviour of HWI for CONST_INT or
>>>>> double-int for CONST_DOUBLE, but I think that's very much a good thing.
>>>>> The model for HWIs at the moment is that you have to truncate results
>>>>> to the canonical form after every operation where it matters.  As you
>>>>> proved in your earlier message about the plus_constant bug, that's
>>>>> easily
>>>>> forgotten.  I don't think the rtl code is doing all CONST_INT
>>>>> arithmetic
>>>>> on full HWIs because it wants to: it's doing it because that's the way
>>>>> C/C++ arithmetic on primitive types works.  In other words, the current
>>>>> CONST_INT code is trying to emulate N-bit arithmetic (for gcc runtime
>>>>> N)
>>>>> using a single primitive integer type.  wide_int gives us N-bit
>>>>> arithmetic
>>>>> directly; no emulation is needed.
>>>>
>>>> Ok, so what wide-int provides is integer values encoded in 'len' HWI
>>>> words that fit in 'precision' or more bits (and often in less).
>>>> wide-int
>>>> also provides N-bit arithmetic operations.  IMHO both are tied
>>>> too closely together.  A give constant doesn't really have a precision.
>>>> Associating one with it to give a precision to an arithmetic operation
>>>> looks wrong to me and are a source of mismatches.
>>>>
>>>> What RTL currently has looks better to me - operations have
>>>> explicitely specified precisions.
>>>
>>> I have tried very hard to make wide-int work very efficiently with both
>>> tree
>>> and rtl without biasing the rep towards either representation.  Both rtl
>>> and
>>> trees constants have a precision.   In tree, constants are done better
>>> than
>>> in rtl because the tree really does have a field that is filled in that
>>> points to a type. However, that does not mean that rtl constants do not
>>> have
>>> a precision: currently you have to look around at the context to find the
>>> mode of a constant that is in your hand, but it is in fact always there.
>>> At the rtl level, you can see the entire patch - we always find an
>>> appropriate mode.
>>
>> Appearantly you cannot.  See Richard S. examples.
>>
>> As of "better", the tree has the issue that we have so many unshared
>> constants because they only differ in type but not in their
>> representation.
>> That's the nice part of RTL constants all having VOIDmode ...
>>
>> Richard.
>
> I said we could always find a mode, i did not say that in order to find the
> mode we did not have to stand on our head, juggle chainsaws and say "mother
> may i".   The decision to leave the mode as void in rtl integer constants
> was made to save space, but comes with an otherwise very high cost and in
> today's world of cheap memory seems fairly dated.   It is a decision that i
> and others would love to change and the truth is wide int is one step in
> that direction (in that it gets rid of the pun of using double-int for both
> integers and floats where the discriminator is voidmode for ints.) But for
> now we have to live with that poor decision.

As far as I have read your wide-int patches the CONST_WIDE_INT RTX
object does not include a mode.  So I don't see it as a step forward in
any way (other than that it makes it explicit that you _do_ need a mode
to do any operation on a constant).

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]