[m-dev.] for discussion: proposed reduction in global registers on x86

[Julien Fischer]

I am proposing to reduce the number of registers that we reserve on
x86 machines for use as global registers in non-PIC Mercury code from
three to two.  In such code we currently reserve %esi, %edi and %ebx.
For PIC we can only use two anyway, since there %ebx is use to
hold the pointer to the GOT.

The reason behind the proposed reduction to lessen the probability of
gcc's register allocator aborting.  This occurs relatively frequently
with x86s due to the lack of registers on those machines.
We encounter this problem from time-to-time and while some instances of
it can be worked around, e.g. in the Mercury runtime, it is more difficult
to deal with in others, e.g. Bison generated parsers embedded
in foreign_code pragmas are a recent example.  Moreover, the gcc
developers don't seem to be particularly interested in fixing such
problems -- there are a number of similar problems in the gcc bug database
that have been unresolved for some years now.

The timings below indicate that making this change will increase
execution overhead by roughly 2.2%.  I think that this is an acceptable
given that from it we will get:

* increased stability with gcc

* the ability to mix PIC and non-PIC code on x86 machines

* a reduction in the complexity of the build system on x86, e.g.
   the whole business with .lpic_o files becomes meaningless.

-------

Timings for the proposed change on our standard benchmark.  These were 
run on jupiter in grade asm_fast.gc.  2-regs is the proposed new 2 global
register version, 3-regs is the existing scheme.

mercury_compile.2-regs 31.249u 0.280s 0:31.52 100.0%	0+0k 0+0io 0pf+0w
mercury_compile.2-regs 31.190u 0.285s 0:31.49 99.9%	0+0k 0+0io 0pf+0w
mercury_compile.2-regs 31.202u 0.304s 0:31.50 100.0%	0+0k 0+0io 0pf+0w
mercury_compile.2-regs 31.204u 0.272s 0:31.48 99.9%	0+0k 0+0io 0pf+0w
mercury_compile.2-regs 31.170u 0.282s 0:31.58 99.5%	0+0k 0+0io 0pf+0w
mercury_compile.2-regs 31.225u 0.258s 0:31.43 100.1%	0+0k 0+0io 0pf+0w
mercury_compile.3-regs 30.515u 0.260s 0:30.76 100.0%	0+0k 0+0io 0pf+0w
mercury_compile.3-regs 30.532u 0.281s 0:30.86 99.8%	0+0k 0+0io 0pf+0w
mercury_compile.3-regs 30.561u 0.281s 0:30.85 99.9%	0+0k 0+0io 0pf+0w
mercury_compile.3-regs 30.598u 0.282s 0:30.88 99.9%	0+0k 0+0io 0pf+0w
mercury_compile.3-regs 30.545u 0.281s 0:30.83 99.9%	0+0k 0+0io 0pf+0w
mercury_compile.3-regs 30.509u 0.323s 0:30.79 100.0%	0+0k 0+0io 0pf+0w

Actually, I suspect for programs that make heavy use of C foreign_procs
you may actually get a performance increase with this change, since the
availability of the extra register should improve gcc's scope for
optimisation - the compiler is not such a program.

Comments?

Julien.

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------