rjmccall added a comment. In D80315#2059160 <https://reviews.llvm.org/D80315#2059160>, @michele.scandale wrote:
> In D80315#2058914 <https://reviews.llvm.org/D80315#2058914>, @rjmccall wrote: > > > In D80315#2058735 <https://reviews.llvm.org/D80315#2058735>, > > @michele.scandale wrote: > > > > > In D80315#2058549 <https://reviews.llvm.org/D80315#2058549>, @rjmccall > > > wrote: > > > > > > > The code cleanups all seems reasonable. The actual changes in > > > > code-generation changes are because we were failing to set these > > > > reliably? > > > > > > > > > Most of them yes. > > > > > > In the CUDA test we there is now `contract` because we honor the default > > > contraction mode that for CUDA is set to fast. > > > > > > Right, and we weren't honoring that mode before? > > > Not in the setup of base fast-math flags inside `CodeGenFunction`. However > when emitting code for expression with `FPOptions` stored in the AST nodes > then `contract` was set correctly. Okay, that seems justifiable. >>> In `clang/test/CodeGen/complex-math.c` I've added `-ffp-contract=fast` to >>> the command line option because `-ffast-math` at the CC1 level does not >>> change the default contraction mode. >> >> Oh, I see, makes sense. So there was inconsistent treatment of the options, >> where one thing observed it but others didn't, and that's been fixed now. > > Do you think we should handle `-ffast-math` as `-cl-fast-relaxed-math`, i.e. > it implies the default contraction mode being "fast"? I'm actually surprised it doesn't. I can't imagine why someone enabling fast math would want contraction to be disabled. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80315/new/ https://reviews.llvm.org/D80315 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
