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] 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


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