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

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

There appear to be multiple but related problems with this testcase.  See
PRs 6621 and 10524.  On machines that define STRICT_ALIGNMENT as 1, the
"SC mode" value is initially placed in a DI mode register.  This is
extracted with this rtl:

(insn 40 39 41 0000000000000000 (set (reg:SF 68)
        (subreg:SF (reg:DI 99) 0)) -1 (nil)
    (nil))

(insn 41 40 42 0000000000000000 (set (reg:SF 69)
	(subreg:SF (reg:DI 99) 4)) -1 (nil)
    (nil))

It would appear that the code that generates the initial rtl is assuming
your first meaning:

> - Set the whole (reg:M2), where the one subreg gets a
>   defined value and the rest is undefined

This is consistent with the treatment you noted in flow.c and the way
we define HARD_REGNO_NREGS on hppa64.  Basically, we assume that we only
need one register to hold a SC object.  However, 20020227-1.c fails on
hppa64 because reload doesn't know how to generate the reloads for
insns 40 and 41.  Thus, while any general and floating point register
can hold an SC mode value, there is no way at the moment to extract
the real and imaginary parts.  Thus, we may need to force "SC mode"
objects into two consecutive registers.  I find the documentation for
HARD_REGNO_NREGS unclear on this point.

My initial attempts at doing this didn't affect the initial rtl
generated for the testcase.  This is probably not surprising as
no rtl in the hppa64 case actually deals with SC mode.

Jan was of the opinion that the subregs shown above were invalid.  Do
others have an opinion on that?

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