[clang] [clang] Set correct FPOptions if attribute 'optnone' presents (PR #85605)

Serge Pavlov via cfe-commits cfe-commits at lists.llvm.org
Tue Mar 19 08:34:42 PDT 2024


spavloff wrote:

> optnone is a very strange attribute; it's a directive to the compiler with no clear semantics.

`fast-math` also does not have clear semantics. It is however used to express user's expectations that some assumptions are valid. `optnone` could also be treated from similar viewpoint. It is very convenient for a user to have a "big switch" that would turn off "all" things that can complicate code generation. Which transformations are optimizations that should be turned off by optnone - it depends on user expectations. Fast-math options are definitely in this list, - they are unsafe transformations aimed at performance.

> And presumably they don't actually want to disable all optimization of their function anyway; they just want to turn off fast math.

They can use `#pragma float_control(precise, on)`. However `optnone`, according to the documentation, is also a legitimate way to turn off fast math.

> I have uploaded your patch and compared the attributes generated from your patch and the little test case from https://github.com/llvm/llvm-project/issues/62098. The attributes generated are different. Therefore, the expected optimizations from this patch are going to be different than what we currently have. I think that's a problem.

Exactly. User specifies attribute `optnone` but the functions has attribute "no-infs-fp-math"="true", which is unsafe optimization. Even if this function is not transformed in IR pipeline, the attribute can cause CodeGen to emit code as if fast-math is in effect. Such behavior contradicts the meaning of `optnone` described in documenttion.

https://github.com/llvm/llvm-project/pull/85605


More information about the cfe-commits mailing list