[llvm-dev] [RFC] Making space for a flush-to-zero flag in FastMathFlags

[Sanjay Patel via llvm-dev]

I don't have any objections to increasing the size of FPMathOperator, but I
also don't know what perf impact that would have.
I made this comment in D39304:
"I don't think we can just add a field to FPMathOperator because Operator
is not intended to be instantiated."
That could just be me not understanding the class hierarchy?

On Mon, Mar 18, 2019 at 11:56 AM Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> On Mon, Mar 18, 2019 at 9:31 AM Sanjay Patel <spatel at rotateright.com>
> wrote:
> >
> > We knew the day when we needed another FMF bit was coming back in:
> > https://reviews.llvm.org/D39304
> > ...it was just a question of 'when'. :)
> >
> > I'm guessing that an FTZ bit won't be the last new bit needed if we
> consider permutations between strict FP and fast-math. Even without that,
> denormals-as-zero (DAZ) might also be useful?
> > So rather than continuing to carve these out bit-by-bit, it's worth
> considering a more general solution: instruction-level metadata.
> >
> > IIUC, the main argument for making FMF part of the instruction was that
> per-instruction metadata gets expensive if we're applying it to a
> significant chunk of the instructions.
> > But let's think about that - even the most FP-heavy code tops out around
> 10% FP math ops out of the total instruction count. Typical FP benchmark
> code is only 2-5% FP ops. The rest is the same load/store/control-flow/ALU
> stuff found in integer code.
>
> If this is true, what do you think about option (1)?  It might be
> simpler to increase the size of FPMathOperator by a word, giving us 64
> more bits of fastmath flags.  We could also have this extra word in
> only those instances of FPMathOperator that have a non-zero
> FastMathFlags (this would force us to remove setFastMathFlags since
> we'd need to know the contents of FastMathFlags at Instruction
> construction time).
>
> -- Sanjoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190318/35204e4f/attachment.html>