This is the mail archive of the gcc@gcc.gnu.org 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: [x86-64 psABI]: Extend x86-64 psABI to support AVX-512


On Thu, Jul 25, 2013 at 12:50:53PM -0400, Rich Felker wrote:
> On Thu, Jul 25, 2013 at 08:55:38AM +0200, OndÅej BÃlka wrote:
> > On Thu, Jul 25, 2013 at 05:06:55AM +0200, Jakub Jelinek wrote:
> > > On Wed, Jul 24, 2013 at 07:36:31PM +0200, Richard Biener wrote:
> > > > >Make them callee saved means we need to change ld.so to
> > > > >preserve them and we need to change unwind library to
> > > > >support them.  It is certainly doable.
> > > > 
> > > > IMHO it was a mistake to not have any callee saved xmm register in the
> > > > original abi - we should fix this at this opportunity.  Loops with
> > > > function calls are not that uncommon.
> > > 
> > > I've raised that earlier already.  One issue with that beyond having to
> > > teach unwinders about this (dynamic linker if you mean only for the lazy PLT
> > > resolving is only a matter of whether the dynamic linker itself has been
> > > built with a compiler that would clobber those registers anywhere) is that
> > > as history shows, the vector registers keep growing over time.
> > > So if we reserve now either 8 or all 16 zmm16 to zmm31 registers as call
> > > saved, do we save them as 512 bit registers, or say 1024 bit already?
> > 
> > We shouldn't save them all as we would often need to unnecessarily save
> > register in leaf function. I am fine with 8. In practice 4 should be
> > enough for most use cases. 
> 
> You can't add call-saved registers without breaking the ABI, because
> they need to be saved in the jmp_buf, which does not have space for
> them.
>
Well you can. Use versioning, structure will not change and layout for
old setjmp/longjmp is unchanged. For new setjmp we set jump address to
jmp_buf address to distinguish it from first case. Then for each thread
we keep a stack with extra space needed to save additional registers. 
When setjmp/longjmp is called we prune frames from exited functions.

 
> Also, unless you add them at the same time the registers are added to
> the machine (so there's no existing code using those registers),
> you'll have ABI problems like this: function using the new call-saved
> registers calls qsort, which calls application code, which assumes the
> registers are call-clobbered and clobbers them; after qsort returns,
> the original caller's state is gone.
>
What are you talking about? Do you mean that user wrongly marked qsort
as a function that does not clobber arguments?

> Adding call-saved registers to an existing psABI is just fundamentally
> misguided.
> 
> Rich


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