[PATCH] D139902: IR: Add nofpclass parameter attribute

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 12 18:34:44 PST 2022


arsenm created this revision.
arsenm added reviewers: jdoerfert, sepavloff, scanon, andrew.w.kaylor, cameron.mcinally, jcranmer-intel, lebedev.ri, nikic, nlopes, foad, spatel, kpn, bkramer, efriedma.
Herald added subscribers: ormris, steven_wu, hiraditya.
Herald added a project: All.
arsenm requested review of this revision.
Herald added a subscriber: wdng.
Herald added a project: LLVM.

This carries a bitmask indicating forbidden floating-point value kinds
in the argument or return value. This will enable interprocedural
-ffinite-math-only optimizations. This is primarily to cover the
no-nans and no-infinities cases, but also covers the other floating
point classes for free. Textually, this provides a number of names
corresponding to bits in FPClassTest, e.g.

  call nofpclass(nan inf) @must_be_finite()
  call nofpclass(snan) @cannot_be_snan()

This is more expressive than the existing nnan and ninf fast math
flags. As an added bonus, you can represent fun things like nanf:

  declare nofpclass(inf zero sub norm) float @only_nans()

Compared to nnan/ninf:

- Can be applied to individual call operands as well as the return value
- Can distinguish signaling and quiet nans
- Distinguishes the sign of infinities
- Can be safely propagated since it doesn't imply anything about other operands.
- Does not apply to FP instructions; it's not a flag

This is one step closer to being able to retire "no-nans-fp-math" and
"no-infs-fp-math". The one remaining situation where we have no way to
represent no-nans/infs is for loads (if we wanted to solve this we
could introduce !nofpclass metadata, following along with
noundef/!noundef).

      

This is to help simplify the GPU builtin math library
distribution. Currently the library code has explicit finite math only
checks, read from global constants the compiler driver needs to set
based on the compiler flags during linking. We end up having to
internalize the library into each translation unit in case different
linked modules have different math flags. By propagating known-not-nan
and known-not-infinity information, we can automatically prune the
edge case handling in most functions if the function is only reached
from fast math uses.


https://reviews.llvm.org/D139902

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  llvm/docs/LangRef.rst
  llvm/docs/ReleaseNotes.rst
  llvm/include/llvm/ADT/FloatingPointMode.h
  llvm/include/llvm/AsmParser/LLParser.h
  llvm/include/llvm/AsmParser/LLToken.h
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Argument.h
  llvm/include/llvm/IR/Attributes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/include/llvm/IR/Function.h
  llvm/include/llvm/IR/InstrTypes.h
  llvm/lib/Analysis/ValueTracking.cpp
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/AttributeImpl.h
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/Function.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp
  llvm/test/Assembler/nofpclass-invalid.ll
  llvm/test/Assembler/nofpclass.ll
  llvm/test/Bitcode/compatibility.ll
  llvm/test/Transforms/InstSimplify/floating-point-compare.ll
  llvm/test/Transforms/InstSimplify/known-never-nan.ll
  llvm/test/Transforms/Util/nofpclass.ll
  llvm/test/Verifier/nofpclass.ll
  llvm/unittests/IR/VerifierTest.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D139902.482330.patch
Type: text/x-patch
Size: 61773 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20221213/f9418b7c/attachment.bin>


More information about the llvm-commits mailing list