Re: solaris build problem with Sun compilers

Поиск
Список
Период
Сортировка
От Alan Stange
Тема Re: solaris build problem with Sun compilers
Дата
Msg-id 4464F242.5060705@rentec.com
обсуждение исходный текст
Ответ на Re: solaris build problem with Sun compilers  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: solaris build problem with Sun compilers
Список pgsql-ports
Tom Lane wrote:
> Alan Stange <stange@rentec.com> writes:
>> - postgresql HEAD when using the Solaris compilers spro9 or newer will
>> only run on v9 based hardware using v8plus or v9 platform.
>> - postgresql HEAD when using gcc will run on anything as they generate
>> code for the v7 platform by default and the cas instruction isn't used
>> in any assembler code in postgresql.
>
> I gather from the contents of solaris_sparc.s that the Sun compilers can
> be expected to define __sparcv9 if compiling for v9 hardware.  I'm
> inclined to #ifdef things so that we use cas if that symbol's defined and
> ldstub if not.  I'm not sure if gcc can be expected to define the same
> symbol --- we might end up using ldstub always, even if we try to
> conditionalize the code for gcc.

This code isn't used by gcc, is it?  Or are you thinking to use the same
  assembler segment in the inline function used by gcc?


> Or we could just revert to ldstub.  This seems like a lot of complexity
> for a so-far-entirely-hypothetical performance gain ...

I suspect that on machines like the UltraSparc T1 (the multi-core boxes)
this can have an impact (lots of additional memory writes).  Even so,
that seems like a stretch.

Was there any reason given for the cas patch?


I might get around to doing the work for the Solaris compiler build to
support the inline keyword as well.   I hacked on it a bit today but had
to get back to real work...

-- Alan

В списке pgsql-ports по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: solaris build problem with Sun compilers
Следующее
От: Tom Lane
Дата:
Сообщение: Re: solaris build problem with Sun compilers