On Mon, Jul 29, 2024 at 02:14:40PM +0200, Richard Biener wrote:
> The following adds a target hook to specify whether regs of MODE can be
> used to transfer bits. The hook is supposed to be used for value-numbering
> to decide whether a value loaded in such mode can be punned to another
> mode instead of re-loading the value in the other mode and for SRA to
> decide whether MODE is suitable as container holding a value to be
> used in different modes.
>
> * target.def (mode_can_transfer_bits): New target hook.
> * target.h (mode_can_transfer_bits): New function wrapping the
> hook and providing default behavior.
> * doc/tm.texi.in: Update.
> * doc/tm.texi: Re-generate.
> --- a/gcc/target.h
> +++ b/gcc/target.h
> @@ -312,6 +312,21 @@ estimated_poly_value (poly_int64 x,
> return targetm.estimated_poly_value (x, kind);
> }
>
> +/* Return true when MODE can be used to copy GET_MODE_BITSIZE bits
> + unchanged. */
> +
> +inline bool
> +mode_can_transfer_bits (machine_mode mode)
> +{
Shouldn't this start with
mode = GET_MODE_INNER (mode);
?
I mean say XCmode has similar problems as XFmode, or
V4SFmode as SFmode if i?86 -mno-sse.
Though, admittedly, with i?86 -msse2 -mfpmath=387 perhaps some vector modes
could work, which would argue for passing even vector modes to the hook.
Though the GET_MODE_BITSIZE != GET_MODE_PRECISION check then wants the inner
modes maybe.
> + if (mode == BLKmode)
> + return true;
> + if (maybe_ne (GET_MODE_BITSIZE (mode), GET_MODE_PRECISION (mode)))
> + return false;
> + if (targetm.mode_can_transfer_bits)
> + return targetm.mode_can_transfer_bits (mode);
> + return true;
> +}
> +
> #ifdef GCC_TM_H
>
> #ifndef CUMULATIVE_ARGS_MAGIC
> --
> 2.35.3
Jakub
