[PATCH] Add new target-hook truncated_to_mode

Richard Sandiford richard@codesourcery.com
Mon Mar 13 08:54:00 GMT 2006


Adam Nemet <anemet@sonic.net> writes:
> Richard Sandiford writes:
>> Adam Nemet <anemet@sonic.net> writes:
>> > If understand your idea correctly then I agree it would.  You
>> > basically want to expose the properties of SIGN_EXTEND and TRUNCATE
>> > together because they really complement each other.
>> 
>> Not really.  This isn't about the properties of SIGN_EXTEND and
>> TRUNCATE, which are just two rtl codes that you use on DImode
>> and SImode values.  It's a property of SImode values themselves.
>> Codes like PLUS have to preserve it too.  (You couldn't implement
>> (plus:SI ...) using 64-bit addition, for example.)
>
> This feels like a little bit of playing with words and perspectives.

Sorry if came across that way.  I honestly wasn't sure whether we were
on the same page.  But from the below, it sounds like we are.

> You still want to expose this behavior through describing properties
> or more precisely equivalences of mode-switching operations.  Instead
> of saying that truncation is not a noop (narrowing subreg) we will now
> say that sign-extension is a noop (widening subreg) which is what I
> meant by these instructions complementing each other.  Or in other
> words instead of:
>
>   narrowing SUBREG != TRUNCATE
>
> we will now say:
>
>   widening SUBREG == SIGN_EXTEND
>
> and try to derive the former property from the latter.  But overall I
> do agree that it usually carries more information to say what
> something _is_ than what it _is not_.

Exactly.  (And clearer than my attempt, I have to admit. ;))
"widening SUBREG == SIGN_EXTEND" describes exactly the property
that the MIPS port is relying on in its implementation of SImode
arithmetic.  It would also allow the middle end to work out more
stuff for itself, including the truncated_to_mode thing.

> I will try to work on this but I am sure since it involves more
> interface changes than my current patch I will have some questions.
> Also I see that you might have a close-to-ready plan in your head.  If
> that is the case you can go ahead and take it over from here.

I can try to find time this week, but no promises.  But really,
I don't see that it _has_ to involve more interface changes than
your current patch.  Like I said in my last reply, you could just
add the new hook as a first step, and use it only in truncated_to_mode.
Everything else -- removing TRULY_NOOP_TRUNCATION, or using the hook
for other optimisations -- could be done incrementally.

Richard



More information about the Gcc-patches mailing list