On Tue, 30 Jul 2024, Paul Koning wrote:

> 
> 
> > 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 agree the wording needs improvement.  I'll try to update it based
on my answer below.

> 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?

If non-float modes are ever allocated to float registers then that would
mean the hook should excempt integer modes.

You are right that this is fundamentally about register classes (or
even instructions).  But the middle-end up to RA has no way to
ensure a register is only placed in a single register class so the
hook asks the target to promise that a register of the specified
mode will always be allocated to a register class suitable for
transfering bits and that loads and store instructions used will
transfer bits from memory unaltered (in case there would for example
be a FP load performing normalization and another load into FP
registers that does not).

It might be possible to re-implement the hook in terms of register
classes and then use the modes register classes this doesn't
capture the x87 situation very well where XFmode is fine but
DFmode is not even though they use the same register file (it's
because of the load instruction).

So I guess for PDP11 the hook wants to exclude all FP modes.

You should possibly see correctness issues with code like

union U { long x; double y; };
void foo(union U *u, union U *u2)
{
  double y = u->y;
  long x = u->x;
  u2->y = y;
  u->x = x;
}

where we perform a double load and pun that to long, possibly
resulting in a different bit-pattern than if loaded from the x
member.

Richard.

Reply via email to