Paul Koning <paulkon...@comcast.net> writes: >> On Jul 30, 2024, at 6:17 AM, Richard Biener <rguent...@suse.de> 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. >> >> ... >> >> +@deftypefn {Target Hook} bool TARGET_MODE_CAN_TRANSFER_BITS (machine_mode >> @var{mode}) >> +Define this to return false if the mode @var{mode} cannot be used >> +for memory copying. The default is to assume modes with the same >> +precision as size are fine to be used. >> +@end deftypefn >> + > > I'm a bit confused about the meaning of this hook; the summary at the top > speaks of type punning while the documentation talks about memory copying. > Those seem rather different. > > I'm also wondering about this being tied to a mode rather than a register > class. To given an example: on the PDP11 there are two main register > classes, "general" and "float". General registers handle any bit pattern and > support arithmetic operations on integer modes; float registers do not > transparently transfer every bit pattern and support float modes. So only > general registers are suitable for memory copies (though on a PDP-11 you > don't need registers to do memory copy). And for type punning, you could > load an SF mode value into general registers (a pair) and type-pun them to > SImode without reloading. > > So what does that mean for this hook on that target?
I think that means that, at the mode level, float modes are not suitable for bit transfer. The hook describes the worst-case behaviour, rather than best-case. Presumably, the fact that integer modes in general have to be value-preserving (and so suitable for the new hook) means that float registers couldn't be used to store integer modes, even ignoring performance concerns. The principle is the same for floats. Either float modes are value-preserving (and so can't be stored in float registers :)) or they're not value-preserving, in which case the new hook must return false. Thanks, Richard