[PATCH] D139481: NVPTX: Cleanup check for denormal mode

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Dec 6 17:05:33 PST 2022


arsenm added inline comments.


================
Comment at: llvm/lib/Target/NVPTX/NVPTXTargetTransformInfo.cpp:374
+        Action.IsHalfTy ? APFloat::IEEEhalf() : APFloat::IEEEsingle());
+    bool FtzEnabled = Mode.Output == DenormalMode::PreserveSign;
 
----------------
tra wrote:
> arsenm wrote:
> > tra wrote:
> > > arsenm wrote:
> > > > Looks broken for double to me but I don't know what the options are
> > > 
> > > Indeed. I do not understand why getDenormalMode appears to single out fp32 as a special case.
> > > 
> > > 
> > Because turn on f32 flush is the option the languages actually expose. denormal-fp-math-f32 acts as an override to denormal-fp-math
> OK, then the code is (and has been) broken for 'double'. I do not think we want to override denormals mode for doubles using `denormal-fp-math-f32`.
> On the other hand, it's no more broken than it was before, so we can probably live with that until we figure out how to fix this.
> 
> https://llvm.org/docs/LangRef.html says:
> >" denormal-fp-math-f32" [...] Not all targets support separately setting the denormal mode per type, and no attempt is made to diagnose unsupported uses. Currently this attribute is respected by the AMDGPU and NVPTX backends.
> 
> On a side note, I wonder if the denormals handling mode may need to grow a similar override for fp16, which also has .ftz instruction variants.
But do those imply a change in the default FP mode, or are they just operations that have flushing semantics in the default mode


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D139481/new/

https://reviews.llvm.org/D139481



More information about the llvm-commits mailing list