This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: (subreg:SF (reg:SC)) question - 20020227-1.c failure
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: weigand at immd1 dot informatik dot uni-erlangen dot de (Ulrich Weigand)
- Cc: gcc at gcc dot gnu dot org, weigand at immd1 dot informatik dot uni-erlangen dot de
- Date: Sun, 4 May 2003 17:26:06 -0400 (EDT)
- Subject: Re: (subreg:SF (reg:SC)) question - 20020227-1.c failure
> David Anglin wrote:
>
> > (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))
>
> [snip]
>
> > Jan was of the opinion that the subregs shown above were invalid. Do
> > others have an opinion on that?
>
> Completely independent of the SCmode question, I don't see why those
> subregs should be invalid. On s390x, you could get something like this
I didn't either, which is why I asked the question. The reason why
the subreg in insn 41 might have been "invalid" is that it arises from
simplification of '(subreg:SC (reg:DI 99) 0)'. The word size/number
of registers issue discussed in the responses to your question comes
into play in this simplification.
> when passing a 'struct { float x; float y; }' as function argument.
> If there's no direct way to perform the move, this should be handled via
> a secondary memory reload ...
This doesn't occur passing a 'struct { float x; float y; }' as function
argument. The float fields are extracted from the incoming argument
register and stored to temp slots. This is done without using any
float modes. They are then loaded from the temp slots with
(insn 23 22 24 0000000000000000 (set (reg:SF 77)
(mem/s/j:SF (reg/f:DI 67) [0 s.x+0 S4 A32])) -1 (nil)
(nil))
(insn 24 23 25 0000000000000000 (set (reg:SF 78)
(mem/s/j:SF (plus:DI (reg/f:DI 67)
(const_int 4 [0x4])) [0 s.y+0 S4 A32])) -1 (nil)
(nil))
I'm going to try adding support to extract SFmode subregs in the pa
backend. This problem would have shown up a lot earlier if 20020227-1.c
hadn't been XFAILed for all targets with "64" in their cpu string :(
Regards,
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)