Hi,
> Would a shift_truncation_mask (rtx op, machine_mode mode) as replacement
> for SHIFT_COUNT_TRUNCATED and the old hook make more sense than just
> relying on the mode? That would be a way to alleviate the first counter
> argument to SHIFT_COUNT_TRUNCATED ("not flexible enough").
Well I think it would be a good idea to fix the issue once and for all in a way
that
works for most targets. I think the best option is to have extra ops that assume
masking of the shift count. If the target supports the optab, the optimizer can
then
change (x << (y & 31)) into (x <<& y) where <<& is the shift+mask operator.
> That said, I don't intend to pursue the proposal given the opinions so
> far - after all it would only save a few lines in our backend and some
> others. I would find it useful to more clearly document the current
> methods as deprecated since they are apparently not useful for any of
> the major targets.
Well I do think it is worth sorting out. It will be more effort to get something
that works for most targets, but it's a long standing issue that shouldn't
really
cause so many issues and a lot of extra work for all targets.
Wilco
