[llvm-dev] Trouble when suppressing a portion of fast-math-transformations

[Sanjay Patel via llvm-dev]

Are we confident that we just need those 7 bits to represent all of the
relaxed FP states that we need/want to support?

I'm asking because FMF in IR is currently mapped onto the
SubclassOptionalData of Value...and we have exactly 7 bits there. :)

If we're redoing the definitions, I'm wondering if we can share the struct
with the backend's SDNodeFlags, but that already has one extra bit for
vector reduction. Should we give up on SubclassOptionalData for FMF? We
have a MD_fpmath enum value for metadata, so we could move things over
there?


On Fri, Sep 29, 2017 at 8:16 PM, Ristow, Warren via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi Hal,
>
> >> 4. To fix this, I think that additional fast-math-flags are likely
> >> needed in the IR.  Instead of the following set:
> >>
> >> 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract'
> >>
> >> something like this:
> >>
> >> 'reassoc' + 'libm' + 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract'
> >>
> >> would be more useful.  Related to this, the current 'fast' flag which
> acts
> >> as an umbrella (enabling 'nnan' + 'ninf' + 'nsz' + 'arcp' + 'contract')
> may
> >> not be needed.  A discussion on this point was raised last November on
> the
> >> mailing list:
> >>
> >> http://lists.llvm.org/pipermail/llvm-dev/2016-November/107104.html
> >
> > I agree. I'm happy to help review the patches. It will be best to have
> > only the finer-grained flags where there's no "fast" flag that implies
> > all of the others.
>
> Thanks for the quick response, and for the willingness to review.  I won't
> let
> this languish so long, like the post from last November.
>
> Happy to hear that you feel it's best not to have the umbrella "fast" flag.
>
> Thanks again,
> -Warren
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171001/1b26477e/attachment.html>