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


Richard Biener <richard.guenther@gmail.com> writes:
> On Fri, Sep 13, 2013 at 10:33 AM, Richard Sandiford
> <rdsandiford@googlemail.com> wrote:
>> Richard Biener <richard.guenther@gmail.com> writes:
>>>> 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).
>>
>> But the point of the gen_int_mode patch is that (for better or worse)
>> CONST_INT is the right choice of rtx for constant CC values.  I'd like
>> eventually to get rid of all GEN_INT callers, and some of those callers
>> will sometimes or always be handling CC modes.  This would then crop up
>> again in a legitimate context.
>>
>> IMO, cse.c was buggy not because it was trying to generate a CCmode
>> CONST_INT, but because anchor optimisations involve addition, which
>> isn't defined for CC modes.
>>
>> I think gen_int_mode should do the right thing for all CONST_INT modes.
>> gen_int_mode (X, MODE) should really be the moral equivalent of
>> gen_rtx_CONST_INT (MODE, X), despite the confusingly-swapped parameters.
>
> Yeah, ok.  But the GEN_INT changes have already uncovered quite some bugs
> so maybe let us discover a few more CCmode bugs first? ...

OK, sounds fair.  I'll hold off the gen_int_mode change until I have
legitimate use.  I went ahead and applied the cse.c change.

Thanks,
Richard


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