On Mon, Jan 02, 2017 at 06:38:28PM +0300, Alexander Monakov wrote:
> I wonder if it's possible to have a small tag in tree types to distinguish
> between binary/decimal/fixed-point types. For prototyping, I was thinking
> about just looking at the type name, because non-ieee-binary types have an
> easily recognizable prefix.
>
> For padding and NaN variability, can you point me on which targets the modes
> affect that? The "Machine Modes" chapter in the documentation doesn't give a
> hint (IFmode/KFmode are not documented there either).
Each target registers its own modes, IFmode/KFmode are e.g. from rs6000.
For floating point modes, one then associates those with some description in
real.[ch] that identifies them. But even on x86_64, there is XFmode and
TFmode, both have the same size, in this case they happen to have different
precision, so precision+size can be used to reconstruct a mode if you know
the mode would have to be one of XFmode or TFmode.
> For attribute-mode, I wasn't aware of KFmode/IFmode stuff; wherever the modes
> affect semantics without leaving any other trace in the type, leaving out the
> mode loses information. So either one keeps the modes, or adds sufficient
> tagging in the type tree.
>
> For long double, I think offloading to PTX should have the following
> semantics:
> size/alignment of long double matches those on host. Otherwise, storage layout
> of composite types won't match, and that's really bad. But otherwise long
> double
> is the same as double on PTX (so for offloading from x86-64 it has 64 bits of
> padding). This means that long double data is not transferable between
> accelerator and host, but otherwise gives the most sane semantics I can
> imagine.
> I think this implies that XFmode/TFmode don't need to exist on NVPTX to back
> long_double_type_node.
If the host has long double the same as double, sure, PTX can use its native
DFmode even for long double. But otherwise, the storage must be
transferable between accelerator and host. If you want to implement very
imprecise XFmode (Intel extended 80-bit double) and TFmode (IEEE quad) for PTX
that
just honors those during memory loads and stores, basically performs what would
cast to double do for loads on the host and cast from double to long double
or __float128 for stores, and performs everything else as DFmode
computations, it might be possible. Or as I said emulate the modes
unsupported on the hw in libgcc.a. Or error out on long double uses as we
do now. People who care about performance with PTX offloading won't use
long double anyway when the HW doesn't support it.
Jakub
