On Thu, Jan 18, 2018 at 12:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Marina Polyakova <m.polyakova@postgrespro.ru> writes:
>> On 18-01-2018 19:53, Tom Lane wrote:
>>> So basically, we're outta luck and we have to consider __int128 as
>>> unsupportable on SPARC. I'm inclined to mechanize that as a test on
>>> $host_cpu. At least that means we don't need an AC_RUN test ;-)
>
>> %-)) :-)
>> Can I do something else about this problem?..
>
> I don't see any other workable alternative. The box we're in as far
> as the interaction with MAXALIGN goes is still the same as it was
> a month ago: raising MAXALIGN is impractical, and so is allowing
> some datatypes to have more-than-MAXALIGN alignment specs.
>
> I suppose you could imagine declaring int128s that are in any sort
> of palloc'd storage as, in effect, char[16], and always memcpy'ing
> to and from local variables that're declared int128 whenever you
> want to do arithmetic with them. But ugh. I can't see taking that
> sort of notational and performance hit for just one non-mainstream
> architecture.
It's not like we'd have to take the performance hit everywhere; we
could do the expensive things only on platforms that need them. The
trick would be to avoid too much notation. But it's not like we don't
live with a lot of DatumGetThing and ThingGetDatum notation already.
> Really, this is something that the compiler ought to do for us, IMO.
> If the gcc guys don't want to be bothered, OK, but that tells you more
> about the priority they place on SPARC support than anything else.
Of course, the same accusation could be leveled at us. We don't
require int128 support for correctness; we just use it for performance
where it's available and works the way we want. Prolly, that means
mainstream platforms. If we wanted to work harder, we could get it
working in other places too. Or some other fix that delivers much of
the same performance benefit.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company