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

[Eli Friedman via llvm-dev]

Yes, FPMathOperator isn’t part of the class hierarchy.  I would interpret “increasing the size of FPMathOperator” as shorthand for increasing the size of ContstantExpr and the relevant subclasses of Instruction.  (Exactly which subclasses of Instruction gets a little sticky because most floating-point operations are represented by BinaryOperator, which is also used for integer arithmetic, but it’s probably solvable somehow.)

-Eli

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Sanjay Patel via llvm-dev
Sent: Monday, March 18, 2019 5:16 PM
To: Sanjoy Das <sanjoy at playingwithpointers.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] Re: [llvm-dev] [RFC] Making space for a flush-to-zero flag in FastMathFlags

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<mailto:sanjoy at playingwithpointers.com>> wrote:
On Mon, Mar 18, 2019 at 9:31 AM Sanjay Patel <spatel at rotateright.com<mailto: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/20190319/6766cc5f/attachment.html>