This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add new target-hook truncated_to_mode
Adam Nemet <anemet@sonic.net> writes:
> Richard Sandiford writes:
>> Adam Nemet <anemet@sonic.net> writes:
>> > This patch adds a new target hook, truncated_to_mode. Currently,
>> > aside from some very special cases we cannot optimize TRUNCATEs for
>> > !TRULY_NOOP_TRUNCATION targets because the semantics of the operation
>> > is target-specific and is not exposed to the middle-end.
>>
>> This caught me out a bit. It seems odd to say that the semantics
>> of _TRUNCATE_ are undefined. I don't think that's really the case.
>> If M1 and M2 are integer modes, (truncate:M1 (foo:M2 ...)) calculates
>> an M1 value that contains the low-order GET_MODE_SIZE (M1) bits of
>> (foo:M2 ...).
>
> Sure. !TRULY_NOOP_TRUNCATION TRUNCATE is undefined for the bits
> outside the destination mode. TRUNCATE is the inverse operation of
> SIGN_EXTEND and ZERO_EXTEND and since the two leave the source-mode
> bits unchanged so must TRUNCATE leave the destination-mode bits
> unchanged. Maybe I didn't say this explicitly but I don't think my
> patch violated this assumption. Do you think it does?
No. That wasn't what I was trying to say. I was just trying to
describe what (as I see it) is going on conceptually, as a basis
for suggesting that LOAD_EXTEND_OP-like hook.
It sounds like you're saying that TRUNCATE has different semantics
depending on TRULY_NOOP_TRUNCATION. I don't believe it does though.
I see TRULY_NOOP_TRUNCATION as controlling a property of SImode itself;
namely that a paradoxical DImode subreg of an SImode value is guaranteed
to be a sign-extension of the SImode value. _All_ SImode operations
have to perserve this property, not just TRUNCATE.
The name "TRULY_NOOP_TRUNCATION" seems a bit unfortunate, which is why
I'd like to get rid of it ;) It seems better to describe the SImode
invariant more directly.
>> So perhaps we should have a hook that, given a pair of modes M1 and
>> M2, returns the rtl code that is implemented by (subreg:M1 (foo:M2
>> ...) 0), or NIL if none. Something a bit like LOAD_EXTEND_OP
>> applied to SUBREGs. That sounds like it would give the middle end
>> more information than the hook in your patch.
>
> 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.)
> There is one difference though. To take advantage of this additional
> information with regard to SIGN_EXTEND we would need to make changes
> to the middle-end. I much rather to this incrementally unless you
> feel that we are at a crossroads and if my changes go in it would
> somehow undermine the more generic approach. I would also prefer to
> work out the details of the interface at that point where we can run
> some tests and analyze results.
I don't really understand what you mean here, but it's possible we're
in complete agreement.
In case this helps to clarify things: I was just describing a different
kind of hook, one that should provide all the information that yours
does, and more. You could easily make truncated_to_mode behave in the
same way with either type of hook. Like you say, there's no need to
change functions besides truncated_to_mode at this stage. We can
add new optimisations incrementally.
But I see no reason to have both hooks side-by-side. So from that
point of view, we _are_ at a crossroads. Which kind of hook do we want?
This is all just a suggestion of course.
Richard