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

Ristow, Warren via llvm-dev
2017-10-03T10:26:05Z

> I agree that using SubclassOptionalData is going to be problematic when we
run out of bits. ...

I don't have a good view of the big-picture here (in terms of the cost of
size and speed of the metadata approach, vs a member of Instruction, vs
something else).

We could tackle this problem now, or defer it hoping that we're not going to
want to add more flags for finer granularity control of fast-math
transformations in the future.  It seems the general sense is that we should
tackle it now.
Sanjay and Hal, is that what you're view is?

-Warren

From: Hal Finkel [mailto:hfinkel at anl.gov]
Sent: Tuesday, October 3, 2017 1:49 AM
To: Sanjay Patel; Ristow, Warren
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Trouble when suppressing a portion of
fast-math-transformations



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
>
> 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




--

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/20171003/218ca916/attachment.html>