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: Using gen_int_mode instead of GEN_INT minot testsuite fallout on MIPS


On Fri, Sep 13, 2013 at 10:08 AM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Richard Biener <richard.guenther@gmail.com> writes:
>>>> (what about partial integer modes which have weird precision (none)?)
>>>
>>> We don't really model that properly yet.  Partial modes are just defined
>>> using something like:
>>>
>>> PARTIAL_INT_MODE (SI);
>>>
>>> i.e. without the partial precision.  But trunc_int_for_mode is based on
>>> GET_MODE_PRECISION, so should just work if a proper precision is added.
>>> (There are other places that wouldn't just work, but that's something
>>> that the wide-int branch will help with.  It almost feels like you were
>>> setting me up for that answer. :-))
>>
>> Well I was asking because if you change a GEN_INT (x) to
>> gen_int_mode (PSImode, x) then you'll end up in trunc_int_for_mode with
>> PSImode which looks at GET_MODE_PRECISION (PSImode is still
>> a SCALAR_INT_MODE_P ...).  We set precision of PSImode to -1U
>> it seems, but that still means that the constant is not even canonicalized
>> to the underlying mode.  (so, should we set partial integer modes precision
>> to the precision of the base mode?  Well, of course we should simply set
>> an appropriate precision at mode definition time)
>
> Yeah.  I don't think it makes sense to canonise PSI to 32 bits when we
> know it has fewer than 32 bits.  It's still going to be wrong, and will
> still defeat one of the main purposes of canonical constants, which is
> to make equality obvious.  E.g. we'd still treat PSI constants
>
>   (const_int 0x...ff80000000)
>
> and
>
>   (const_int 0x...ffc0000000)
>
> as different, even though they're both zero for a 24-bit PSI.
>
> This partial integer mode stuff is just a big hack.  Like you say,
> we can only really do something sensible if we know what the real
> precision is.
>
> So I'd rather leave things as they are for this series.  The precision
> effectively becomes 65535 thanks to the underlying unsigned short array,
> so like you say, trunc_int_for_mode is a no-op for partial modes.
> Changing GEN_INT to gen_int_mode shouldn't make any difference.
>
> What do you think about the patch for CC modes?

I wonder if we can do without changing gen_int_mode by fixing the callers
like you did for cse.c (that patch is ok).

Richard.

> Thanks,
> Richard


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