llvm dev - Oct 2017 - Trouble when suppressing a portion of fast-math-transformations

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

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>

I'm not aware of any additional bits needed.  But putting us right at the
edge leaves me uncomfortable.  So an implementation that isn't limited by
the 7 bits in SubclassOptionalData seems sensible.

Thanks,
-Warren

From: Sanjay Patel [mailto:spatel at rotateright.com]
Sent: Monday, October 2, 2017 12:06 AM
To: Ristow, Warren
Cc: Hal Finkel; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Trouble when suppressing a portion of
fast-math-transformations

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<mailto: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<mailto: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/20171002/d69e4328/attachment.html>

On 10/01/2017 06:05 PM, Sanjay Patel wrote:
> 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?
I agree that using SubclassOptionalData is going to be problematic when 
we run out of bits. As I recall, the reason that we didn't use metadata 
in the first place was because metadata is (generically) expensive. This 
case is very much like the case of debug info: in some modes, we add the 
debugging metadata to nearly every instruction. We use metadata for 
debug locations, syntactically, but we actually have a DebugLoc in each 
instruction that's used for the underlying representation. Here we'd 
have a similar problem: in some modes, we'd add this metadata to a large 
subset of all instructions. That could measurably slow down the 
optimizer. We may need to find some other place to put the data (e.g., 
an actual member variable of Instruction or more tail-allocated data in 
places)

  -Hal
>
>
> On Fri, Sep 29, 2017 at 8:16 PM, Ristow, Warren via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto: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
>    
<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 <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>
>
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171002/ddae8942/attachment.html>