Re: solaris build problem with Sun compilers
От | Alan Stange |
---|---|
Тема | Re: solaris build problem with Sun compilers |
Дата | |
Msg-id | 446C7204.8030001@rentec.com обсуждение исходный текст |
Ответ на | Re: solaris build problem with Sun compilers (Theo Schlossnagle <jesus@omniti.com>) |
Список | pgsql-ports |
Theo Schlossnagle wrote: > > 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. I think that's what was written above... > 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. linking the postgresql libpq with code compiled at v8 is the only reason that I can think of. v8plus has been the default in the Sun compilers for some time now, so this would only be an issue for an older binary. As far as I can tell, gcc still produces v7 code by default and knows nothing about v8plus. Even better would be using v8plusb with the Sun compilers. -- Alan
В списке pgsql-ports по дате отправления: