i686 pic & DCmode

In poking at another set of fails encountered with an i686-elf toolchain 
(http://gcc.gnu.org/ml/gcc/2013-08/msg00081.html), I find that complex double 
returns and PIC do not play together.

Libgcc's __muldc3 was attempting to return the value in registers, whereas every 
caller expected it to be returned via pointer-to-aggregate parm.  Turned out to 
be PIC at fault -- libgcc is built as PIC, the callers weren't.

To determine if the return value should go in memory, function.c contains 
aggregate_value_p, which really means 'can't return in registers'.  That calls 
the backend return_in_mem hook, which for i686-elf simply forces BLKmode things 
to memory (the bundle of fun I refer to in the link).  As this is DCmode, we 
fall through to the default behaviour, which after a few other checks, picks the 
return register and then looks to see if the span of registers needed for the 
object are all call clobbered.

On x86, the registers are numbered eax, edx, ecx, ebx.  The first 3 are call 
clobbered and ebx is call preserved.  Hence (in non PIC), DCmode objects can't 
be placed there and a pointer-to-result parm is added.  In PIC mode, ebx remains 
call preserved, but becomes a fixed regs.  A fixed reg must also set call_used, 
and hey presto, we suddenly think all 4 are call clobbered.

This causes the result to be placed in those 4 registers -- and then the 
epilogue code restores the incoming ebx value, for extra brokenness.

The usual x86 ports avoid this, because their must_return_in_mem hooks DTRT 
already and we never fall into the default case.

I am very surprised this hasn't bitten someone before -- I presume this never 
worked with i686-elf.  It is possible this'll change some other ABI where a 
fixed reg was permitted to be used in the manner that this now prohibits, but I 
have a hard time thinking that happens.  Shout if you know of one.

Anyhow, I've not run a full regression test with this patch, but it does 
indicate that the i686-elf config's ABI is a bunch of accidents, rather than a 
coherent design.

nathan
2013-08-07  Nathan Sidwell  <nathan@codesourcery.com>

	gcc/
	* function.c (aggregate_value_p): Don't use a fixed reg either.

> The usual x86 ports avoid this, because their must_return_in_mem hooks DTRT
> already and we never fall into the default case.

So why not do the same for i686-elf?

> I am very surprised this hasn't bitten someone before -- I presume this
> never worked with i686-elf.  It is possible this'll change some other ABI
> where a fixed reg was permitted to be used in the manner that this now
> prohibits, but I have a hard time thinking that happens.  Shout if you
> know of one.

IMO that's not sufficient, you ought to go through all the back-ends and check 
that you aren't breaking anything with such a bold change.  This code is more 
than 2 decades old and can affect every single port in a major way.

Having poked further, I find this in the testsuite:

pr11001-strlen-2.c
--begin
register int regvar asm("%eax");

char *
do_copy (char *str)
{
   return malloc (strlen (str) + 1);
}
--end

Is that even meaningful?  The doc's for a global reg var say:
'Choose a register that is normally saved and restored by function calls on your
machine, so that library routines will not clobber it.'

If one never made calls to a library unaware of the reg's global use, things 
would be ok.  Except if one chose a register that is used by the ABI to return 
things, or by the pro/epilogue code as a scratch register.

Should attempts to use a call_used reg as a global reg var generate an error? 
Should it stop it being marked as a fixed_reg?

nathan

On Wed, Aug 7, 2013 at 10:34 AM, Nathan Sidwell <nathan@acm.org> wrote:
> Having poked further, I find this in the testsuite:
>
> pr11001-strlen-2.c
> --begin
> register int regvar asm("%eax");
>
> char *
> do_copy (char *str)
> {
>   return malloc (strlen (str) + 1);
> }
> --end
>
> Is that even meaningful?  The doc's for a global reg var say:
> 'Choose a register that is normally saved and restored by function calls on
> your
> machine, so that library routines will not clobber it.'

This is risky but meaningful, and potentially useful with asm
instructions.

> If one never made calls to a library unaware of the reg's global use, things
> would be ok.  Except if one chose a register that is used by the ABI to
> return things, or by the pro/epilogue code as a scratch register.
>
> Should attempts to use a call_used reg as a global reg var generate an
> error?

No.  Perhaps a warning.

> Should it stop it being marked as a fixed_reg?

Definitely not.

Ian