Re: modified x86 ABI

[David Taylor <dtaylor at emc dot com>]

> Date: Tue, 23 Oct 2007 10:07:03 +0200
> From: "Uros Bizjak" <ubizjak@gmail.com>
> 
> Hello!
> 
> > At EMC we have a version of GCC which targets the x86 with a non
> > standard ABI -- it produces code for 64 bit mode mode, but with types
> > having the 32 bit ABI sizes.  So, ints, longs, and pointers are 32
> > bits -- that is, it's ILP32 rather than LP64 -- but with the chip in
> > 64 bit mode.
> 
> > If this set of changes was cleaned up, finished, and made relative to
> > top of trunk rather than relative to 3.4.6, would people be interested
> > in them?
> 
> Just recently, there was a discussion about memory consumpltion of
> 64bit x86 binaries [1], so your patch would address these issues.
> Perhaps you should read a thread starting from [1], where some of the
> issues regarding ABI change are already discussed.
> 
> > Put another way, should I bother to post them to gcc-patches (probably
> > 3-6 months out) for possible inclusion into gcc?
> 
> If there are indeed ~50% memory savings from using ILP32 instead of
> LP64, as speculated in [1], then I'm sure that  functionality that
> brings goodies from 32bit (memory savings) and 64bit (new registers)
> would find a lot of uses. We can introduce (for example) -mabi=32+
> switch and experiment there.

Our motivation was not less memory use, per se.  It was performance.
And porting effort.

We have a code base -- an ILP32 code base -- which runs on a variety
of platforms including x86.  If we can use 64 bit mode, then we have
more registers available, hopefully less register pressure, and less
saving / restoring on function call / return, and the like.  And
hopefully this wins over the need to extend / truncate pointers.

Preliminary results indicate that we get 5%-15% better performance
-- for our application -- than with the traditional 32 bit x86 ABI.

> OTOH, we are currently in development stage-3 and your proposed
> timeline fits nicely in the time frame for new stage-1.

Yes.  I generally closely follow the gcc, gcc-patches, and gcc-bugs
mailing lists (though I'm currently over a month behind -- work has
been too busy recently to keep up as closely as I'd like).

We have some preliminary results and since the system boots and runs,
that means that the compiler isn't totally broken. :) But, I don't yet
have the testsuite running, so I'm not completely sure how robust it
is.

My estimate assumes both that things don't take significantly longer
than expected and that priorities don't change at work.

> [1] http://gcc.gnu.org/ml/gcc/2007-10/msg00156.html
> 
> Uros.