[PATCH][X86] Add ISel patterns to select 'fp32_to_fp16' and 'fp16_to_fp32' dag nodes.

[Andrea Di Biagio]

Hi Jim,

On Fri, Jun 20, 2014 at 9:32 PM, Jim Grosbach <grosbach at apple.com> wrote:
> I agree calling library helpers is the correct fallback here.
>
> What’s the behavior with soft-float? Specifically,
>
> +  if (!TM.Options.UseSoftFloat && !Subtarget->hasF16C()) {

I have just run some tests (using the test-case from this patch)
with/without flag -float-abi=soft/hard.
The presence/absence of that flag doesn't seem to affect the output.

My originally idea was to generate library calls for
float-to-half-float conversions if 'soft' float-abi was specified.
I thought that the presence of that flag would have affected the
codegen for those dag nodes. But apparently I was wrong.

>
> -Jim
>
>> On Jun 19, 2014, at 6:53 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com> wrote:
>>
>> Hi,
>>
>> this patch:
>> 1) Adds tablegen patterns to select F16C float-to-half-float
>> conversion instructions (and vice versa) from 'f32_to_f16' (and
>> 'f16_to_f32') dag nodes;
>>
>> 2) Teaches the backend how to emit compiler runtime library call to
>> __gnu_f2h_ieee and __gnu_h2f_ieee if there is no F16C support.
>>
>> About point 2.
>> I am not sure if there is a better ways to fix/workaround this
>> problem. In general, my opinion is that the backend shouldn't raise a
>> error if we don't have F16C and the DAG contains
>> 'f32_to_f16/f16_to_f32' nodes.
>>
>> The compiler already knows about the existence of libcalls
>> '__gnu_f2h_ieee' and '__gnu_h2f_ieee2' (see TargetLoweringBase.cpp).
>> So, my idea (if you agree) is to generate runtime calls instead of
>> returning an ISel error.
>> However, this could result later on in a linker error if the runtime
>> library doesn't define '__gnu_f2h_ieee' and '__gnu_h2f_ieee'.
>>
>> Please let me know what you think.
>>
>> Thanks!
>> Andrea Di Biagio
>> <patch-f16c-conv.diff>
>