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

[Sanjoy Das via llvm-dev]

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