|
From: Florian K. <br...@ac...> - 2012-05-27 16:49:04
|
Hi Julian,
I was wondering whether you would be OK with this clarification wrt what
helper calls may do.
Index: pub/libvex_ir.h
===================================================================
--- pub/libvex_ir.h (revision 2334)
+++ pub/libvex_ir.h (working copy)
@@ -1662,6 +1662,11 @@
* it must not assume that arguments are being evaluated in a
particular order. The oder of evaluation is unspecified.
+ * it must not leave hardware control registers in a modified
+ state (e.g. if the call modifies the floating point control
+ register it must restore it to the state it had when entering
+ the callee)
+
This is restrictive, but makes the semantics clean, and does
not interfere with IR optimisation.
@@ -1863,6 +1868,9 @@
arguments are evaluated REGARDLESS of the guard value. The order of
argument evaluation is unspecified. The guard expression is evaluated
AFTER the arguments have been evaluated.
+
+ The helper function must not leave hardware control registers in a
+ modified state (see clean helpers).
*/
#define VEX_N_FXSTATE 7 /* enough for FXSAVE/FXRSTOR on x86 */
The rationale is that, at least in theory, helper calls (clean and
dirty) can modify control regs for whatever reason. But if they do, they
should restore them before returning. The s390 helper call machinery
currently stores the floating point control register on the stack before
calling a helper and restores it afterwards. If we put this burden on
the helper function, I could save these two instructions.
Florian
|
|
From: Julian S. <js...@ac...> - 2012-05-27 17:49:54
|
Hi Florian, So it _sounds_ plausible .. but I wonder how this interacts with the ABI's definitions of what is supposed to happen. I say this because the C compiler compilers the helpers and therefore whatever it saves/restores is what the ABI says. Eg, imagine there is some floating point control register FPCR, and the ABI says that FPCR is caller saved. That means we don't have a way to implement the requirement > + * it must not leave hardware control registers in a modified > + state (e.g. if the call modifies the floating point control > + register it must restore it to the state it had when entering > + the callee) outside of inserting inline assembly at the start/end of the helper to save/restore FPCR. Or do I misunderstand something? As a consequence of the above .. > should restore them before returning. The s390 helper call machinery > currently stores the floating point control register on the stack before > calling a helper and restores it afterwards. If we put this burden on > the helper function, I could save these two instructions. .. my belief is that either (1) the s390 ELF ABI says that this register is callee save, in which case you can get rid of the instructions, or (2) it says they are caller save, in which case the instructions would have to stay. As per the comments above I don't think you have the option of removing the instructions from the generated code and putting them in the helper, at least not if the helper is written in vanilla C. Yell if I got the wrong end of the stick on this .. J |
|
From: Florian K. <br...@ac...> - 2012-05-27 20:55:21
|
On 05/27/2012 01:47 PM, Julian Seward wrote:
> So it _sounds_ plausible .. but I wonder how this interacts with the ABI's
> definitions of what is supposed to happen. I say this because the C compiler
> compilers the helpers and therefore whatever it saves/restores is what
> the ABI says.
Good point.
When I wrote this I was thinking about bits in the control reg that
specify the rounding mode.
> Eg, imagine there is some floating point control register FPCR, and the
> ABI says that FPCR is caller saved.
Yes, e.g. ppc. The thing is that the fpcr not only contains bits to
specify the rounding mode, it also contains bits that refer to the
outcome of the last floating point operation (overflow, underflow and
such). That is what I overlooked. So from that perspective it's
extremely likely that such a control register is caller-saved. (ppc abi
says so; s390x abi is silent about that, but its fpc is caller-saved).
However, a quick experiment shows that the caller-saved property only
refers to the flag bits in the fpcr not to the bits specifying the
rounding mode. GCC on ppc (and s390x) clearly assumes, that those are
callee-saved.
Consider
extern double v1, v2;
double func()
{
foobar();
// no code is generated here to restore the rounding mode in the fpcr
return v1+v2;
}
So if foobar is allowed to trash the fpcr then code would have to be
inserted to restore the rounding mode prior to the addition. That's not
happening.
> .. my belief is that either (1) the s390 ELF ABI says that this register
> is callee save, in which case you can get rid of the instructions, or
> (2) it says they are caller save, in which case the instructions would
> have to stay.
Right, I cannot eliminate those insns, as I need to preserve the
floating point flags.
Florian
|
|
From: Julian S. <js...@ac...> - 2012-05-28 09:24:57
|
On Sunday, May 27, 2012, Julian Seward wrote: > Eg, imagine there is some floating point control register FPCR, and the > ABI says that FPCR is caller saved. Callee saved, I meant to say. J |