regparm

[james dot g dot mansion at hsbcgroup dot com]

I have a (possibly rather naive) suggestion about this facility.

(
First, though, while I would agree with Linus to some extent in terms of
'giving up', I would say that I think:
 - it is irresponsible to use a compiler facility that is known to be both
a compiler-specific extension and to have an unreliable implementation
 - agruably, disabling such extensions is absolutely the right thing to do
 -its very sad that the kind of control that I enjoyed with Watcom C isn't
available anyway

Personally I'd rather the C code in the kernel didn't use ANY extensions
and was just plain C.  You want inline, you use C++.

But I digress.
)

Anyway, back to the suggestion:

It is my understanding that:
-the compiler generates code that evaluates arguments and pushes them onto
the stack as soon as the argument is ready.  This ends the lifetime of the
implied temporary (or pseudo register or whatever your terminology is)
which is generally a Good Thing.
-if the compiler is attempting to pass arguments in registers then instead
of pushing onto the stack, it will assign it into a register.
-the compiler may erroneously use a register that has a parameter wired
into it in order to evaluate a subsequent argument - it does not perform
the necessary spill and reload.

Now, would it be possible (in the case of register parameter passing only)
to extend the life of the temporary/pseudo until ALL arguments to the
called function are completely ready, and then assign into hard registers?
If such a final assignment could cause problems then I'd expect life would
be somewhat difficult already.

Might it be necessary for the compiler to create temporary variables in the
stack frame to do it?

Suppose we have:

#define x (big nasy expression)
#define y (another big nasty expression)
foo(x,y);

And the intermediate code is something like:

(calc y ending with ...)
p1=y
push p1        ' pseudo p1 is now dead
(calc x ending with ...)
p2 = x
push p2        ' pseudo p2 is now dead
call foo

Except that for register calling we have:

(calc y ending with ...)
p1=y
$R1=p1
(calc x ending with ...)
p2=x
$R2=p2
call foo

We want this to be:

(calc y ending with ...)
p1=y
(calc x ending with ...)
p2=x
R1=p1
R2=p2
call foo

(I am assuming that in this case the compiler will correctly spill/reload
p1 from its register if necessary in the calculation of y and assignment to
p2)

Is it the case, if the compiler front end had emitted RTL that mirrored
code looking like:

TX tmpX;
TY tmpY;

tmpX=x
tmpY=y
foo(tmpX,tmpY);

Would this result in reliable code, or will the optimiser 'helpfully'
propagate the calculations for x,y directly into the call,remove tmpX, tmpY
as dead code,and reorder the calcs and reg assignments so that we still
have a problem?

If this form were used, and the register presure is light (ie x and y are
not 'big nasty expression's at all) then would the machine description
manage to eliminate tmpX, tmpY?

My hope here is that the problem could be solved by emitting a different
RTL form for the call sequence rather than messing with the register
allocator itself - at least as a temporary measure.

Just an idea.  Apologies if my notation isn't clear.

James



************************************************************************
Midland Bank plc, who is regulated in the UK by SFA, has issued the
information contained in this message (including any attached documents)
for its non-private customers only. It should not be reproduced and/or
distributed to any other person. It is not an invitation to buy or sell
securities. Opinions may change without notice and members of the 
HSBC Group may have positions in, or trade in instruments mentioned in
this message. Each page attached hereto must also be read in conjunction
with any disclaimer which form part of it.
************************************************************************