Re: Your change to emit_group_{load,store}

[Aldy Hernandez <aldyh at redhat dot com>]

I know rth already fixed this, but I still think the PPC back-end
is generating confusing RTL:

> (parallel:TF [
>         (expr_list:REG_DEP_TRUE (reg:DF 45 f13 [ g ])
>             (const_int 0 [0x0]))
>     ])

What does this mean exactly?  It *doesn't* mean that the value goes
partly in the stack, because that's specified with the first operand
of the first expr_list being zero.

If TF should go in multiple locations (in DF registers), it would be 
something like this:

	(parallel:TF [
		(expr_list (reg:DF f13) (const_int 0))
		(expr_list (reg:DF f14) (const_int 8)))

For that matter, I don't understand why we can't just return:

	(reg:TF f13)

...and let GCC do the rest.  Perhaps to cover some hidden bug?

Alan, in a separate discussions mentioned:

   It's saying that the TF goes partly in f13.  The other piece will go on
   the stack.  I'm not sure exactly why plain f13 without the parallel
   wrapper doesn't work.  Possibly it would be OK.  Getting rid of
   "&& mode == fmode" in these lines from rs6000.c:function arg would do
   that for you.

          if (!needs_psave && mode == fmode)
            return gen_rtx_REG (fmode, cum->fregno);

   ...

   Later..
   I played a bit with removing the mode == fmode test, and found gcc
   generated worse code

Hmmm... looks like a bug elsewhere.  I'd still like to know what the
parallel was doing there in the first place.  But I ain't going to lose
much sleep over it ;-).

Dazed and confused.