MIPS h asm constraint in GCC 4.4, and TI-mode 128 bit types

[Andrew Haley]

Jack Lloyd wrote:

> I noted this change in the GCC 4.4 notes:
> 
> """
> The MIPS port no longer recognizes the h asm constraint. It was
> necessary to remove this constraint in order to avoid generating
> unpredictable code sequences.
> 
> One of the main uses of the h constraint was to extract the high part
> of a multiplication on 64-bit targets. For example:
> 
>     asm ("dmultu\t%1,%2" : "=h" (result) : "r" (x), "r" (y));
> 
> You can now achieve the same effect using 128-bit types:
> 
>     typedef unsigned int uint128_t __attribute__((mode(TI)));
>     result = ((uint128_t) x * y) >> 64;
> """
> 
> I am currently using exactly the sort of asm construct given in the
> note to access dmultu.
> 
> Can anyone tell me at what point was this mode(TI) business supported,
> and on which platforms? It seems to be accepted by GCC 4.3.3 on
> x86-64. But I cannot seem to find much about it in the info pages for
> that version - it seems analogous to the TC and XC modes mentioned in
> 5.10 Additional Floating Types, and TI mode is mentioned in
> conjunction with full-vector SSE2 access, but that doesn't tell me
> much (firstly since SSE2 doesn't have a 64x64->128 multiply
> instruction, and of course since MIPS does not have SSE2 anyway).
> 
> If this works consistently across platforms that would be
> exceptionally useful for me, as currently I use inline asm to access
> the native 64-bit multiply on various platforms (x86-64 mulq, IA-64
> xmpy.hu, PPC mulhdu, Alpha umulh, MIPS dmultu), and if all can be
> consolidated using this TI construct that certainly makes my life
> simpler.

TImode has been in gcc for a very long time.  However, it's not necessarily
available on every gcc back-end, but I think it's there for all 64-bit
targets.  I just tried your example on 3.2.3, x86-64 and it's fine.

Andrew.