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 по дате отправления: