Robin Dapp <rd...@linux.ibm.com> writes:
>>> Bit tests on x86 also truncate [1], if the bit base operand specifies
>>> a register, and we don't use BT with a memory location as a bit base.
>>> I don't know what is referred with "(real or pretended) bit field
>>> operations" in the documentation for SHIFT_COUNT_TRUNCATED:
>>>
>>> However, on some machines, such as the 80386 and the 680x0,
>>> truncation only applies to shift operations and not the (real or
>>> pretended) bit-field operations. Define 'SHIFT_COUNT_TRUNCATED' to
>>>
>>> Vector shifts don't truncate on x86, so x86 probably shares the same
>>> destiny with MIPS. Maybe a machine mode argument could be passed to
>>> SHIFT_COUNT_TRUNCATED to distinguish modes that truncate from modes
>>> that don't.
>>
>> But IL semantic differences based on mode is even worse. What happens
>> if STV then substitues a vector register/op but you previously optimized
>> with the assumption the count would be truncated since the shift was SImode?
>>
>> IMHO a recipie for desaster.
>
> 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"). Richard's
> argument about the premature optimization however, I can agree on and I
> don't see a way to avoid this. Doesn't it apply to other middle-end
> optimizations as well, though, and is handled via additional flags that
> prohibit selected follow-up optimizations?
>
> The problem with my proposed unifying is that the hook is/will be called
> by RTL as well as tree passes and would need to have an argument type
> that can hold all of their respective shift-like operations in order to
> return a useful mask. My local version uses an rtx that only contains
> an rtx_code which is filled in an ad-hoc fashion for the tree passes.
>
> 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.
The hook and macro do different things though. The hook just describes
the behaviour of named shift patterns like ashl<mode>3. The only reason
we have it is so that target-independent code can rely on certain
behaviour when using these patterns (via optabs) to generate new
shift instructions.
In other words, the hook only applies to a specific target interface and
doesn't change the meaning of the IL. By giving the guarantee that the
shift optabs use a certain mask, the target has to ensure somehow that
the instructions generated by the optabs really do honour that mask.
But the target has to do that using the existing rtl semantics; the hook
doesn't change what the shift rtx codes mean.
Major targets can and do use that, and it helps expand generate more
efficient code for doubleword operations (which was the original reason
for adding it). So I think the hook is still useful and shouldn't be
deprecated.
IMO we should only consider deprecating the macro. I'm not sure how
much practical effect that will have though. cc0 was deprecated ages
ago but we're a still a long way from getting rid of it. :-)
Thanks,
Richard
