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?
