Re: [AArch64] Enable generation of FRINTNZ instructions

[Andre Simoes Dias Vieira <andre.simoesdiasvieira@arm.com>]

On 12/11/2021 10:56, Richard Biener wrote:
> On Thu, 11 Nov 2021, Andre Vieira (lists) wrote:
>
>> Hi,
>>
>> This patch introduces two IFN's FTRUNC32 and FTRUNC64, the corresponding
>> optabs and mappings. It also creates a backend pattern to implement them for
>> aarch64 and a match.pd pattern to idiom recognize these.
>> These IFN's (and optabs) represent a truncation towards zero, as if performed
>> by first casting it to a signed integer of 32 or 64 bits and then back to the
>> same floating point type/mode.
>>
>> The match.pd pattern choses to use these, when supported, regardless of
>> trapping math, since these new patterns mimic the original behavior of
>> truncating through an integer.
>>
>> I didn't think any of the existing IFN's represented these. I know it's a bit
>> late in stage 1, but I thought this might be OK given it's only used by a
>> single target and should have very little impact on anything else.
>>
>> Bootstrapped on aarch64-none-linux.
>>
>> OK for trunk?
> On the RTL side ftrunc32/ftrunc64 would probably be better a conversion
> optab (with two modes), so not
>
> +OPTAB_D (ftrunc32_optab, "ftrunc$asi2")
> +OPTAB_D (ftrunc64_optab, "ftrunc$adi2")
>
> but
>
> OPTAB_CD (ftrunc_shrt_optab, "ftrunc$a$I$b2")
>
> or so?  I know that gets somewhat awkward for the internal function,
> but IMHO we shouldn't tie our hands because of that?
I tried doing this originally, but indeed I couldn't find a way to 
correctly tie the internal function to it.

direct_optab_supported_p with multiple types expect those to be of the 
same mode. I see convert_optab_supported_p does but I don't know how 
that is used...

Any ideas?