This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC PATCH, x86_64] Use -mno-sse[,2] to fall back to x87 FP argument passing convention

> On 10 Oct 2006 22:35:03 -0700, Ian Lance Taylor <> wrote:
> >
> >Incidentally, I've thought that it might be interesting to experiment
> >with an x86_64 ABI which used ILP32, but which used the extra eight
> >registers, passed parameters in registers, and only preserved the low
> >32-bits of the caller-saved registers.  For applications which could
> >live in a 32-bit address space, that would save the memory traffic
> >required to save and restore 64-bit registers on function entry and
> >exit.  The result would be pretty similar to i386 code, but with 8
> >more registers.  It should definitely run faster than i386 code, and I
> >think that due to improved memory traffic it would also run faster
> >than standard x86_64 code.  But I haven't actually tried.
> This idea pops up every once in a while.  I think Honza even prototyped
> it, but of course it adds yet another architecture (or set of multilibs).  
> So
> unless the improvement is very big (like getting rid of the
> old 32bit ABI completely...) it isn't going to happen I guess.

Yep, I didn't saved only the low 32-bits, just made pointers 32bit zero
extended and it sort of worked as expected - the memory bound SPEC
scores, such as vpr has improved significantly, some benchmarks slowed
down due to zero extends somewhat and programs increased in size little
too overall at that point it was about 4% SPECint win, but things change
with CPU performance/memory hiearchy performance ratio and this was done
long time ago.  The ugly part is the need for multilib in the whole
distribution and also for kernel emulation layer (for stuff like ioctls,
Linux kernel is not quite ready for 3 different ABIs at a time) if you
want to implement this correctly, so there is long way from benchmark
quality prototype to production quality environment and
(maintenance/disk space) costs are quite high so it was concluded that
we should not walk down this path.

> Richard.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]