how long to keep support for gcc on x86?

[John-Mark Gurney]

John Baldwin wrote this message on Mon, Jan 14, 2013 at 11:10 -0500:
> On Sunday, January 13, 2013 8:24:02 am Konstantin Belousov wrote:
> > On Sun, Jan 13, 2013 at 12:09:09AM -0800, Peter Wemm wrote:
> > > On Sat, Jan 12, 2013 at 11:44 PM, Adrian Chadd <adrian at freebsd.org> wrote:
> > > 
> > > > Thus I think adding clang-only code to the system right now is very,
> > > > very premature. There still seem to be reasons to run systems on GCC
> > > > instead of clang.
> > > 
> > > I don't have a problem with it so long as the system isn't *broken* if
> > > you're not using clang.  ie: if the status-quo is maintained for gcc
> > > systems and g-faster bits are enabled with clang.  It's fine to
> > > provide incentives to try clang, but it is not ok to regress the gcc
> > > case.
> > Absolutely agree.
> > 
> > Please note that in the AES-NI case, gcc 'support' is only partially
> > gcc issue, if gcc at all. Our 2.17 gas does not know about AES-NI
> > mnemonics and cannot assemble them.
> 
> It is not but so hard to add new instructions to binutils.  I did it recently 
> for the xsave stuff as well the instructions needed by bhyve.  How many 
> instructions are you talking about (and which ones)?

Would adding them to binutils support inline assembly?  Though
supporting them in gas would be useful tool, but inline assembly would
be best (so the compiler can do register allocation optimizations)..

The instructions are aesenc, aesenclast, aesdec, aesdeclast..  And if
you want to be complete, aeskeygenassist, aesimc, pclmulqdq...  Though
pclmulqdq isn't currently used...

I'm willing to do some of the work and debugging too, just I don't know
which files to modify, etc...  I couldn't find any good guides on the
internet that talks about this..

Thanks.

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."