Re: [PATCH] Add new target-hook truncated_to_mode

[Adam Nemet <anemet at sonic dot net>]

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?

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

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.

Or of course if you think that there are correctness issues with my
patch that is different question.  You've seen that the gain is quite
significant as it is.  It would also help to continue my work to fix
correctness issues in the truncation code in the middle-end without
effecting performance too much.

What do you think?

Adam