On Fri, 14 Jul 2023, Andrew MacLeod wrote:
>
> On 7/14/23 09:37, Richard Biener wrote:
> > On Fri, 14 Jul 2023, Aldy Hernandez wrote:
> >
> >> I don't know what you're trying to accomplish here, as I haven't been
> >> following the PR, but adding all these helper functions to the ranger
> >> header
> >> file seems wrong, especially since there's only one use of them. I see
> >> you're
> >> tweaking the irange API, adding helper functions to range-op (which is only
> >> for code dealing with implementing range operators for tree codes), etc
> >> etc.
> >>
> >> If you need these helper functions, I suggest you put them closer to their
> >> uses (i.e. wherever the match.pd support machinery goes).
> > Note I suggested the opposite beacuse I thought these kind of helpers
> > are closer to value-range support than to match.pd.
>
>
> probably vr-values.{cc.h} and the simply_using_ranges paradigm would be the
> most sensible place to put these kinds of auxiliary routines?
>
>
> >
> > But I take away from your answer that there's nothing close in the
> > value-range machinery that answers the question whether A op B may
> > overflow?
>
> we dont track it in ranges themselves. During calculation of a range we
> obviously know, but propagating that generally when we rarely care doesn't
> seem worthwhile. The very first generation of irange 6 years ago had an
> overflow_p() flag, but it was removed as not being worth keeping. easier
> to simply ask the question when it matters
>
> As the routines show, it pretty easy to figure out when the need arises so I
> think that should suffice. At least for now,
>
> Should we decide we would like it in general, it wouldnt be hard to add to
> irange. wi_fold() cuurently returns null, it could easily return a bool
> indicating if an overflow happened, and wi_fold_in_parts and fold_range would
> simply OR the results all together of the compoent wi_fold() calls. It would
> require updating/audfiting a number of range-op entries and adding an
> overflowed_p() query to irange.
Ah, yeah - the folding APIs would be a good fit I guess. I was
also looking to have the "new" helpers to be somewhat consistent
with the ranger API.
So if we had a fold_range overload with either an output argument
or a flag that makes it return false on possible overflow that
would work I guess? Since we have a virtual class setup we
might be able to provide a default failing method and implement
workers for plus and mult (as needed for this patch) as the need
arises?
Thanks,
Richard.
