llvm dev - Jul 2014 - [LLVMdev] RFC: Do we still need @llvm.convert.to.fp16 and the reverse?

Hi all,

What do people think of doing away with the @llvm.convert.to.fp16 and
@llvm.convert.from.fp16 intrinsics, in favour of using "half" and
fpext/fptrunc? [1]

It looks like those intrinsics originally date from before "half"
actually existed in LLVM, and of course the backends have grown up
assuming that's what Clang will produce, so we'd have to improve their
support first. But the benefit would be a more uniform interface to
this type, both for front-ends and backends.

I've been poking around a bit, and as far as I can see the following
accommodations would need to be made in CodeGen:

1. Generic support to Promote f16 operations narrowed by InstCombine
back to f32.

And in Targets:

1. If there's *no* native f16 support, they can probably remain unchanged.
2. Targets with scalar f16 conversion would need it to become a legal
type (in some register class). This seems like a reasonable
requirement if there actually are instructions acting on it. But it
adds the usual overheads of supporting bitcasts and loads/stores.
3. Targets with vector f16 conversion would similarly need to legalize
the type (and in this case would probably need argument-passing
support too, since Clang forbids passing a direct __fp16 but not a
vector).

I think it would be a worthwhile change, but want to make sure backend
owners with an interest in f16 don't object to the direction. That'd
seem to be: AArch64, ARM, NVPTX, R600 and X86.

Cheers.

Tim.

[1] I think this is an orthogonal issue to whether __fp16 is a
storage-only type or actually gets native arithmetic operations: we
can still have Clang promote any value to float before actually doing
anything.

On Mon, Jul 14, 2014 at 01:08:54PM +0100, Tim Northover
wrote:
> Hi all,
> 
> What do people think of doing away with the @llvm.convert.to.fp16 and
> @llvm.convert.from.fp16 intrinsics, in favour of using "half" and
> fpext/fptrunc? [1]
> 
I am in favor of using fpext/fptrunc instead of the intrinsics.
> It looks like those intrinsics originally date from before "half"
> actually existed in LLVM, and of course the backends have grown up
> assuming that's what Clang will produce, so we'd have to improve
their
> support first. But the benefit would be a more uniform interface to
> this type, both for front-ends and backends.
> 
> I've been poking around a bit, and as far as I can see the following
> accommodations would need to be made in CodeGen:
> 
> 1. Generic support to Promote f16 operations narrowed by InstCombine
> back to f32.
> 
Are there any in-tree targets that natively support fp16 operations?

-Tom
> And in Targets:
> 
> 1. If there's *no* native f16 support, they can probably remain
unchanged.
> 2. Targets with scalar f16 conversion would need it to become a legal
> type (in some register class). This seems like a reasonable
> requirement if there actually are instructions acting on it. But it
> adds the usual overheads of supporting bitcasts and loads/stores.
> 3. Targets with vector f16 conversion would similarly need to legalize
> the type (and in this case would probably need argument-passing
> support too, since Clang forbids passing a direct __fp16 but not a
> vector).
> 
> I think it would be a worthwhile change, but want to make sure backend
> owners with an interest in f16 don't object to the direction.
That'd
> seem to be: AArch64, ARM, NVPTX, R600 and X86.
> 
> Cheers.
> 
> Tim.
> 
> [1] I think this is an orthogonal issue to whether __fp16 is a
> storage-only type or actually gets native arithmetic operations: we
> can still have Clang promote any value to float before actually doing
> anything.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Mon, 2014-07-14 at 07:23 -0700, Tom Stellard wrote:
> On Mon, Jul 14, 2014 at 01:08:54PM +0100, Tim Northover wrote:
> > Hi all,
> > 
> > What do people think of doing away with the @llvm.convert.to.fp16 and
> > @llvm.convert.from.fp16 intrinsics, in favour of using
"half" and
> > fpext/fptrunc? [1]
> > 
> 
> I am in favor of using fpext/fptrunc instead of the intrinsics.
I don't see any issues with NVPTX here.  Since we have a 'half' type
in
LLVM IR, it makes sense to go ahead and use it instead of having a half
value be either 'i16' or 'half' depending on what you're
trying to do
with it.
> 
> > It looks like those intrinsics originally date from before
"half"
> > actually existed in LLVM, and of course the backends have grown up
> > assuming that's what Clang will produce, so we'd have to
improve their
> > support first. But the benefit would be a more uniform interface to
> > this type, both for front-ends and backends.
> > 
> > I've been poking around a bit, and as far as I can see the
following
> > accommodations would need to be made in CodeGen:
> > 
> > 1. Generic support to Promote f16 operations narrowed by InstCombine
> > back to f32.
> > 
> 
> Are there any in-tree targets that natively support fp16 operations?
> 
> -Tom
> 
> > And in Targets:
> > 
> > 1. If there's *no* native f16 support, they can probably remain
unchanged.
> > 2. Targets with scalar f16 conversion would need it to become a legal
> > type (in some register class). This seems like a reasonable
> > requirement if there actually are instructions acting on it. But it
> > adds the usual overheads of supporting bitcasts and loads/stores.
> > 3. Targets with vector f16 conversion would similarly need to legalize
> > the type (and in this case would probably need argument-passing
> > support too, since Clang forbids passing a direct __fp16 but not a
> > vector).
> > 
> > I think it would be a worthwhile change, but want to make sure backend
> > owners with an interest in f16 don't object to the direction.
That'd
> > seem to be: AArch64, ARM, NVPTX, R600 and X86.
> > 
> > Cheers.
> > 
> > Tim.
> > 
> > [1] I think this is an orthogonal issue to whether __fp16 is a
> > storage-only type or actually gets native arithmetic operations: we
> > can still have Clang promote any value to float before actually doing
> > anything.
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

Historically the only reason for these intrinsics was the lack of
native support for f16 on any target. On ARM f16 was storage only, so
stuff was promoted to / from float at every operation.

Looks like we need to be very careful here and not to change
storage-only semantics. Besides this I'm ok with dropping them.

On Mon, Jul 14, 2014 at 4:08 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
> Hi all,
>
> What do people think of doing away with the @llvm.convert.to.fp16 and
> @llvm.convert.from.fp16 intrinsics, in favour of using "half" and
> fpext/fptrunc? [1]
>
> It looks like those intrinsics originally date from before "half"
> actually existed in LLVM, and of course the backends have grown up
> assuming that's what Clang will produce, so we'd have to improve
their
> support first. But the benefit would be a more uniform interface to
> this type, both for front-ends and backends.
>
> I've been poking around a bit, and as far as I can see the following
> accommodations would need to be made in CodeGen:
>
> 1. Generic support to Promote f16 operations narrowed by InstCombine
> back to f32.
>
> And in Targets:
>
> 1. If there's *no* native f16 support, they can probably remain
unchanged.
> 2. Targets with scalar f16 conversion would need it to become a legal
> type (in some register class). This seems like a reasonable
> requirement if there actually are instructions acting on it. But it
> adds the usual overheads of supporting bitcasts and loads/stores.
> 3. Targets with vector f16 conversion would similarly need to legalize
> the type (and in this case would probably need argument-passing
> support too, since Clang forbids passing a direct __fp16 but not a
> vector).
>
> I think it would be a worthwhile change, but want to make sure backend
> owners with an interest in f16 don't object to the direction.
That'd
> seem to be: AArch64, ARM, NVPTX, R600 and X86.
>
> Cheers.
>
> Tim.
>
> [1] I think this is an orthogonal issue to whether __fp16 is a
> storage-only type or actually gets native arithmetic operations: we
> can still have Clang promote any value to float before actually doing
> anything.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

On 14 July 2014 21:37, Anton Korobeynikov <anton at korobeynikov.info>
wrote:
> Looks like we need to be very careful here and not to change
> storage-only semantics. Besides this I'm ok with dropping them.
If that's similar to named registers (@llvm.read_register and
@llvm.write_register), than staying as intrinsics is a good choice for
that very reason.

--renato

On Jul 14, 2014, at 7:23 AM, Tom Stellard <tom at stellard.net> wrote:
> On Mon, Jul 14, 2014 at 01:08:54PM +0100, Tim Northover wrote:
>> Hi all,
>> 
>> What do people think of doing away with the @llvm.convert.to.fp16 and
>> @llvm.convert.from.fp16 intrinsics, in favour of using "half"
and
>> fpext/fptrunc? [1]
>> 
> 
> I am in favor of using fpext/fptrunc instead of the intrinsics.

The problem with this is the half type assumes you have half registers. I came
up with some ugly hack that involved forcing custom lowering to make half
loads/stores work for R600, but it was much easier to handle the intrinsic. The
16-bit integer type extload to the 32-bit register with the intrinsic for the
half conversion just worked (see r212676)

> 
>> It looks like those intrinsics originally date from before
"half"
>> actually existed in LLVM, and of course the backends have grown up
>> assuming that's what Clang will produce, so we'd have to
improve their
>> support first. But the benefit would be a more uniform interface to
>> this type, both for front-ends and backends.
>> 
>> I've been poking around a bit, and as far as I can see the
following
>> accommodations would need to be made in CodeGen:
>> 
>> 1. Generic support to Promote f16 operations narrowed by InstCombine
>> back to f32.
>> 
> 
> Are there any in-tree targets that natively support fp16 operations?
> 
> -Tom
> 
>> And in Targets:
>> 
>> 1. If there's *no* native f16 support, they can probably remain
unchanged.
>> 2. Targets with scalar f16 conversion would need it to become a legal
>> type (in some register class). This seems like a reasonable
>> requirement if there actually are instructions acting on it. But it
>> adds the usual overheads of supporting bitcasts and loads/stores.
>> 3. Targets with vector f16 conversion would similarly need to legalize
>> the type (and in this case would probably need argument-passing
>> support too, since Clang forbids passing a direct __fp16 but not a
>> vector).
>> 
>> I think it would be a worthwhile change, but want to make sure backend
>> owners with an interest in f16 don't object to the direction.
That'd
>> seem to be: AArch64, ARM, NVPTX, R600 and X86.
>> 
>> Cheers.
>> 
>> Tim.
>> 
>> [1] I think this is an orthogonal issue to whether __fp16 is a
>> storage-only type or actually gets native arithmetic operations: we
>> can still have Clang promote any value to float before actually doing
>> anything.
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140714/bdede027/attachment.html>