Richard Henderson <rth@xxxxxxxxxx> writes:
> On Tue, Aug 31, 2004 at 08:51:20PM +0100, Richard Sandiford wrote:
>> int TARGET_SHIFT_TRUNCATION_MASK (enum machine_mode MODE)
> ...
>> Note that, unlike `SHIFT_COUNT_TRUNCATED', this function does
>> _not_ apply to general shift rtxes; it applies only to instructions
>> that are generated by the named shift patterns.
>
> I'm not particularly thrilled about this notion. I'd much prefer a
> target hook that could replace SHIFT_COUNT_TRUNCATED. How often are
> the named patterns going to differ from the rtxes anyway?
Well, the problem is that SHIFT_COUNT_TRUNCATED applies to all shift
rtxes, including those synthesised by things like combine.c:expand_
compound_operation(). I assume that's why SHIFT_COUNT_TRUNCATED is
documented as follows:
A C expression that is nonzero if on this machine the number of bits
actually used for the count of a shift operation is equal to the number
of bits needed to represent the size of the object being shifted. When
this macro is nonzero, the compiler will assume that it is safe to omit
a sign-extend, zero-extend, and certain bitwise `and' instructions that
truncates the count of a shift operation. On machines that have
instructions that act on bit-fields at variable positions, which may
include `bit test' instructions, a nonzero @code{SHIFT_COUNT_TRUNCATED}
also enables deletion of truncations of the values that serve as
arguments to bit-field instructions.
If both types of instructions truncate the count (for shifts) and
position (for bit-field operations), or if no variable-position bit-field
instructions exist, you should define this macro.
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 @code{SHIFT_COUNT_TRUNCATED} to be zero on
such machines. Instead, add patterns to the @file{md} file that include
the implied truncation of the shift instructions.
I was deliberately trying to avoid this fuzziness with the new target hook.
E.g., if it ever becomes useful to know that ashlsi3 truncates on x86,
then it will be possible to use the new hook there too, even though the
requirements of S_C_T aren't met.
Richard
