jcranmer-intel wrote: > I'm not sure what the correct behavior is across all platforms. My > perspective on this is heavily X86-biased, so I'd really like some guidance > from people who work on other targets about their expectations. I think I saw > at least one target that sets denormal-fp-math=preservesign as their default > even without any fast-math options enabled. It wouldn't surprise me if there > are targets that don't want to set denormal-fp-math=preservesign even with > fast-math.
Some of the GPU targets, IIRC, want daz/ftz by default. Not all targets have DAZ/FTZ bits that can be set; I think RISC-V is in this category, although to be honest, trying to track down all the ISA extensions to make sure is a bit beyond my ken. I kinda do long for the day when daz/ftz can be consigned to the same sort of dustbin of history as, say, EBCDIC. > For some(?) Linux targets, we've got the mess I'm touching here where the > driver is looking for crtfastmath.o and trying to inspect the command-line > for fast-math settings outside the other FP option rendering, and then the FP > option rendering, which is meant to be target-independent, is kind of making > a mess of it, especially with inconsistent handling of "denormal-fp-math" and > "denormal-fp32-math". The issue here I think is that of the Linux targets, only the x86 people cared enough to get the denormal-fp-math set correctly, but the logic actually applies across targets. It's a real mess since some targets flush to positive zero and some targets flush to signed zero and some manuals I couldn't make heads or tails out of what they actually did. https://github.com/llvm/llvm-project/pull/89477 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
