This is the mail archive of the
mailing list for the GCC project.
Re: LTO remapping/deduction of machine modes of types/decls
- From: Alexander Monakov <amonakov at ispras dot ru>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gcc at gcc dot gnu dot org, Richard Biener <rguenther at suse dot de>, Vladislav Ivanishin <vlad at ispras dot ru>
- Date: Mon, 2 Jan 2017 18:38:28 +0300 (MSK)
- Subject: Re: LTO remapping/deduction of machine modes of types/decls
- Authentication-results: sourceware.org; auth=none
- References: <alpine.LNX.email@example.com> <20170102101931.GB21933@tucnak>
On Mon, 2 Jan 2017, Jakub Jelinek wrote:
> In my view mode is essential part of the type system. It (sadly, but still)
> participates in many ABI decisions, but more importantly especially for
> floating point types it is the main source of information of what the type
> actually is, as just size and precision are nowhere near enough.
> The precision/size isn't able to carry information like whether the type is
> decimal or binary floating, what padding it has and where, what NaN etc.
> conventions it uses. So trying to throw away modes and reconstruct them
> looks conceptually wrong to me.
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).
Alternatively, is reconstructing all modes necessary in the first place? On
tree level GCC has explicit trees for all fundamental types like
float_type_node. Is it possible to remap just those trees? Modes of composite
types should be deducible, and modes of decls may be deducible from their types
(not sure; why do decls have modes separately from their types, anyway?)
> One can also just use
> float __attribute__((mode (XFmode))) or float __attribute__((mode (TFmode)))
> or float __attribute__((mode (KFmode))) or IFmode etc., how do you want to
> differentiate between those? And I don't see how this can help with the
> long double stuff for NVPTX offloading. If user uses 80-bit long double
> (or mode(XFmode) floats/doubles) in his source, then as PTX only has SFmode
> and DFmode (perhaps also HFmode?), the only way to get it working is through
> emulation (whether soft-fp, or writing some emulation using double,
> whatever). Pretending long double on the host is DFmode on the PTX side
> just won't work, they have different representation.
(yes, PTX spec has half floats, but GCC doesn't implement those on PTX today,
and thus doesn't have HFmode now)
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