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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
