[PATCH] Add a simple fraction class

Richard Biener richard.guenther@gmail.com
Mon Aug 2 11:07:02 GMT 2021


On Mon, Aug 2, 2021 at 12:43 PM Richard Sandiford
<richard.sandiford@arm.com> wrote:
>
> Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
> > On Fri, Jul 30, 2021 at 5:59 PM Richard Sandiford via Gcc-patches
> > <gcc-patches@gcc.gnu.org> wrote:
> >>
> >> This patch adds a simple class for holding A/B fractions.
> >> As the comments in the patch say, the class isn't designed
> >> to have nice numerial properties at the extremes.
> >>
> >> The motivating use case was some aarch64 costing work,
> >> where being able to represent fractions was much easier
> >> than using single integers and avoided the rounding errors
> >> that would come with using floats.  (Unlike things like
> >> COSTS_N_INSNS, there was no sensible constant base factor
> >> that could be used.)
> >>
> >> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?
> >
> > Hmm, we use the sreal type for profiles.  I don't see any overflow/underflow
> > handling in your class - I suppose you're going to use it on integer types
> > given we're not allowed to use native FP?
>
> Yeah, I'm going to use it on integer types.  And it's not designed
> to have nice properties at extremes, including handling underflow and
> overflow.

So maybe assert that it doesn't?  In particular nominator/denominator
are prone to overflowing in fractional representations.

There's the option to round or ICE.  Or rather than the only option
is to round (or use a more expensive arbitrary precision representation).

So the question is whether the fractional behavior is better in more
cases than the sreal behavior (I can easily believe it is).

> I want to use it in costing code, where we already happily multiply
> and add “int”-sized costs without worrying about overflow.  I'll be
> using uint64_t for the fractions though, just in case. :-)
>
> sreal doesn't help because it's still significand/exponent.  That matters
> because…
>
> > I mean, how exactly does
> > the class solve the problem of rounding errors?
>
> …I wanted something that represented the results exactly (barring any of
> integer ops overflowing).  This makes it meaningful to compare costs for
> equality.  It also means we can use ordered comparisons without having
> to introduce a fudge factor to cope with one calculation having different
> intermediate rounding from the other.

I think you're underestimating how quickly your denominator will overflow?
So I suppose all factors of all possible denominators are known, in fact
whats your main source for the divisions?  The VF?

> E.g. aarch64 has code like:
>
>       if (scalar_cycles_per_iter < sve_estimate)
>         {
>           unsigned int min_cost
>             = orig_body_cost * estimated_poly_value (BYTES_PER_SVE_VECTOR);
>           if (body_cost < min_cost)
>             {
>               if (dump_enabled_p ())
>                 dump_printf_loc (MSG_NOTE, vect_location,
>                                  "Increasing body cost to %d because the"
>                                  " scalar code could issue within the limit"
>                                  " imposed by predicate operations\n",
>                                  min_cost);
>               body_cost = min_cost;
>               should_disparage = true;
>             }
>         }
>
> I want to be able to keep this while making scalar_cycles_per_iter and
> sve_estimate non-integral.
>
> Thanks,
> Richard


More information about the Gcc-patches mailing list