From: | Alan Stange <stange(at)rentec(dot)com> |
---|---|
To: | Theo Schlossnagle <jesus(at)omniti(dot)com> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-ports(at)postgresql(dot)org |
Subject: | Re: solaris build problem with Sun compilers |
Date: | 2006-05-18 13:09:24 |
Message-ID: | 446C7204.8030001@rentec.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)rentec(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-05-18 16:02:55 | Re: solaris build problem with Sun compilers |
Previous Message | Alan Stange | 2006-05-18 12:40:36 | Re: solaris build problem with Sun compilers |