This is the mail archive of the
mailing list for the GCC project.
Re: [GSoC-19] Expanding fromfp variants on AArch64
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Tejas Joshi <tejasjoshi9673 at gmail dot com>
- Cc: <gcc at gcc dot gnu dot org>, Martin Jambor <mjambor at suse dot cz>, <hubicka at ucw dot cz>
- Date: Mon, 19 Aug 2019 14:43:06 +0000
- Subject: Re: [GSoC-19] Expanding fromfp variants on AArch64
- Ironport-sdr: or9oOw+uiiAiJ1eLD9NmxGtaNuitF17xUZFKoBgzM+NFi35b8wrZ4DmSRjeRdI931TWomyVW/p 3c8+wxEnLSalDNqe+P9QpvyjzqTsfPenTDq3WndIgos3L8rFur9QoUA9xo+aHk8cSrpK5nE0jw ocxy18tZl7yy16qV+gswLOvGd43n9qbl6CdAh5sOUWZSbxDmnN8jUXYLfGD3MIuZFzBlkbLkVM UTvvUPzQthL4fLO9OH0u75/OKfiiExOCC+h39Khxfbsvq5g4DA6ZmLqzxHT+8oVvvKU0GDviph nCY=
- Ironport-sdr: rNcJcTcmO3bWpjAYb2Jd49QKjfj9CIoWFfC7TMadx35nUspnWIHRFRaEK8DGuyB3EJaE8iCbyH TPOiTjVY4wec457+gfys3Pc6knM4P6cgzdp/HDEtRapJGRejJKfZQBQ1Scski5JuMoaUkXcWr5 p5uDlf7xNO8oyKDtV0VMCQXO6+vfXxxO8Pp+lF0DrrgLalY1LvZHRPunzLtlp4OnpFSnnyu5h4 T/OKQUqEJLc3ZtM6/cRrlBj5JFLN9K9e67VM6ZHEfD9WED4BVQKULjGIfbBk3z2tedNJCrTBtV ox8=
- References: <CACMrGjBWoU3Ao8sTCiBpNQqGNSO5c6Ezq7goqsGXu-EXiySZzw@mail.gmail.com>
On Mon, 19 Aug 2019, Tejas Joshi wrote:
> How can I add a target hook to specify the FP_INT_* values from libm ?
You'll need a GCC-specific enum (GCC_FP_INT_*, say) that GCC uses
internally, and a hook that maps between that and FP_INT_*. I'm guessing
that for the likely uses, maybe the hook should map from FP_INT_* to
GCC_FP_INT_* (so it gets used on constant arguments to the built-in
function to say which rounding direction they are in GCC's internal enum).
It will need to be able to return that a constant doesn't map to a known
rounding mode (not an error, just means that call can't be expanded inline
or optimized to a constant).
Then the relevant macro giving the default for glibc systems should be
defined in config/gnu-user.h (see how it defines e.g.
> Also as this includes rounding to integers, does it involve any RTL
> related complications that we have encountered in FADD ?
The new RTL would effectively be variants of the fix_trunc and
fixuns_trunc patterns, which can use (fix) and (unsigned_fix) RTL; the new
variants would take an argument in a floating-point mode, returning one in
an integer mode - but with extra information involved about the number of
bits, rounding direction, handling of "inexact".
fix_trunc and fixuns_trunc / (fix) and (unsigned_fix) always use
FP_INT_TOWARDZERO, always use the width of the mode and have unspecified
"inexact" handling for non-integer in-range values (they correspond to C
casts) so are not themselves suitable for implementing the new built-in
functions (but the particular instructions those patterns expand to are
likely to be suitable for certain arguments to certain of the new built-in
Joseph S. Myers