Re: solaris build problem with Sun compilers
От | Theo Schlossnagle |
---|---|
Тема | Re: solaris build problem with Sun compilers |
Дата | |
Msg-id | 8D4484B1-3256-41F4-AFD2-8ABFB4B914BE@omniti.com обсуждение исходный текст |
Ответ на | Re: solaris build problem with Sun compilers (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: solaris build problem with Sun compilers
|
Список | pgsql-ports |
On May 17, 2006, at 8:04 PM, Bruce Momjian wrote: > Bruce Momjian wrote: >> Tom Lane wrote: >>> Alan Stange <stange@rentec.com> writes: >>>> I believe the trick here is that Solaris 10 will only run on v9 >>>> hardware >>>> (or the sun4u systems), which all have the instruction. But >>>> the v8 ABI >>>> "model" doesn't have it. So, in some sense the ABI doesn't >>>> "allow" >>>> this instruction, but the hardware does, so they can just slam >>>> it in >>>> knowing that it'll work. >>> >>> Well, that might be OK for Sun's compiler since they know what a >>> given >>> version of Solaris will run on. But I don't think we can adopt >>> the same >>> attitude for our gcc code path; that has to work on Sparc-based >>> Linuxen >>> and BSDen. I don't think it's appropriate to kiss off support >>> for v8 >>> chips when we haven't seen any proof at all of a performance >>> boost in >>> return. >>> >>> Maybe the right answer is to leave the code as-is, ie, >>> deliberately not >>> the same for Sun and gcc compilers. >> >> OK, I have applied the following patch which documents that the >> Solaris >> CC TAS ASM only works for sparc9. Hopefully either sparc8 is not >> needed >> (unlikely) or someone will fix it. I have CC'ed the original >> contributor who added "cas". > > Oh, I just found this email that has a simplified sparc8 asm: > > http://archives.postgresql.org/pgsql-ports/2006-05/msg00025.php > > Attached is the new solaris_sparc.s file with the #ifdef sparc8 test; > applied. I don't think that asm does what you think it does. That hex encoding of the cas instruction doesn't work on Sparcv8, only sparcv8plus. The reason that it is hacked that way is that, for other reasons, they can't use the -xarch=v8plus flag (despite compiling on v8plus capable chips). Basically that code hardcodes a v8plus instruction into a v8 binary "knowing" that it will never run on a non-v8plus capable chip. The reason that they can do this is because they (as I understand it) open solaris won't support any chips so old as to not run v8plus code. We shouldn't be suffering from that problem and -xarch=v8plus should be used to produce 32-bit binaries and -xarch=v9 should be used to produce 64-bit sparc binaries. I can't think of a reason to every compile the Postgres source with -xarch=v8 instead of -xarch=v8plus, the latter will produce much better code overall. // Theo Schlossnagle // CTO -- http://www.omniti.com/~jesus/ // OmniTI Computer Consulting, Inc. -- http://www.omniti.com/ // Ecelerity: Run with it.
В списке pgsql-ports по дате отправления: