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