Re: (subreg:SF (reg:SC)) question - 20020227-1.c failure

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

Hi Ulrich,

Thanks for sending the patch.

> In addition to this patch, I needed to add a movstrictsf insn to
> the s390 backend (kind of obvious ...), and also tweak it to
> force complex values to always use at least two registers, 
> even when they would theoretically fit into a single one 
> (allowing that breaks horribly in reload for some reason I don't 
> quite understand -- something to do with subreg_offset_representable_p 
> failing ...).

I've been looking at subreg_offset_representable_p.  I still
don't understand what "representable" means completely but I think
the routine is broken for big endian targets.  In particular,
this adjustment seems very strange:

  /* The XMODE value can be seen as an vector of NREGS_XMODE
     values.  The subreg must represent an lowpart of given field.
     Compute what field it is.  */
  offset -= subreg_lowpart_offset (ymode, 
				   mode_for_size (GET_MODE_BITSIZE (xmode)
						  / nregs_xmode,
					 	  MODE_INT, 0));

When the routine is passed an offset of 0 on a big endian target, this
results in y_offset being -1 (xmode=SCmode, ymode=SFmode).  As a result,
the routine returns false on a 64-bit target with mode_multiple = 2
and nregs_multiple = 1.

If I change the routine so that it returns true for an offset 0
(the high part of the SCmode value) and provide the patterns in the
backend to handle the strict_low_part subreg insns, then things seem
to work with a single register.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)