Date: Mon, 14 Jan 2013 14:42:04 -0700 From: Warner Losh <imp@bsdimp.com> To: John-Mark Gurney <jmg@funkthat.com> Cc: Konstantin Belousov <kostikbel@gmail.com>, Adrian Chadd <adrian@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: how long to keep support for gcc on x86? Message-ID: <DFD4C242-3484-4B02-B137-C9A237AD24C5@bsdimp.com> In-Reply-To: <20130114212215.GV1410@funkthat.com> References: <20130112233147.GK1410@funkthat.com> <CAGE5yCoT4NZ2ULS60oZTXhQGgTbLRMZRvHmzioS7ToK9L8aZ_A@mail.gmail.com> <20130113132402.GR2561@kib.kiev.ua> <201301141110.44165.jhb@freebsd.org> <20130114212215.GV1410@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 14, 2013, at 2:22 PM, John-Mark Gurney wrote: > 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@freebsd.org> = wrote: >>>>=20 >>>>> 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. >>>>=20 >>>> 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. >>>=20 >>> 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. >>=20 >> It is not but so hard to add new instructions to binutils. I did it = recently=20 >> for the xsave stuff as well the instructions needed by bhyve. How = many=20 >> instructions are you talking about (and which ones)? >=20 > 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).. Yes, of course. gcc, unlike clang, doesn't have a builtin assembler and = the inline assembler is passed through. With the proper register = annotation, gcc will do the proper register alloation, etc. > The instructions are aesenc, aesenclast, aesdec, aesdeclast.. And if > you want to be complete, aeskeygenassist, aesimc, pclmulqdq... Though > pclmulqdq isn't currently used... >=20 > 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.. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DFD4C242-3484-4B02-B137-C9A237AD24C5>