This is an archive of the discontinued LLVM Phabricator instance.

Additionally set f32 mode with denormal-fp-math
ClosedPublic

Authored by dcandler on Mar 28 2022, 8:48 AM.

Details

Summary

When the denormal-fp-math option is used, this should set the
denormal handling mode for all floating point types. However,
currently 32-bit float types can ignore this setting as there is a
variant of the option, denormal-fp-math-f32, specifically for that type
which takes priority when checking the mode based on type and remains
at the default of IEEE. From the description, denormal-fp-math would
be expected to set the mode for floats unless overridden by the f32
variant, and code in the front end only emits the f32 option if it is
different to the general one, so setting just denormal-fp-math should
be valid.

This patch changes the denormal-fp-math option to also set the f32
mode. If denormal-fp-math-f32 is also specified, this is then
overridden as expected, but if it is absent floats will be set to the
mode specified by the former option, rather than remain on the default.

Diff Detail

Event Timeline

dcandler created this revision.Mar 28 2022, 8:48 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 28 2022, 8:48 AM
dcandler requested review of this revision.Mar 28 2022, 8:48 AM
Herald added a project: Restricted Project. · View Herald TranscriptMar 28 2022, 8:48 AM
dcandler updated this revision to Diff 418865.Mar 29 2022, 7:05 AM

Added a test that checks attributes based on the -fdenormal-fp-math and -fdenormal-fp-math-f32 flags.

Only the cases where -fdenormal-fp-math is set to preserve-sign or positive-zero and -fdenormal-fp-math-f32 is unset are changed by this patch. Previously, these would still result in a "denormal-fp-math-f32"="ieee,ieee" attribute.

I think my intent here was to not emit denormal-fp-math-f32 at all if it wasn't specified (i.e. denormal-fp-math-f32 is a special override only really used for AMDGPU)

The interaction between the two and the default is supposed to be handled by the backend interpretation of the attributes. Does this fix an observable problem for you?

The issue I found was trying to use getDefaultDenormalModeForType during constant folding to account for denormals (https://reviews.llvm.org/D116952). Setting denormal-fp-math to a non-IEEE mode without specifying denormal-fp-math-f32 still results in the denormal-fp-math-f32 attribute being present (even if unsued elsewhere), which leads to the wrong result for targets that do not support denormal-fp-math-f32.

Only emitting denormal-fp-math-f32 when specified makes sense, but the current default effectively always specifies it as IEEE. One alternative would be to simply change the default.

arsenm accepted this revision.Apr 18 2022, 1:33 PM

LGTM. I played around with this and it seems to have the overriding behavior I would expect

clang/test/CodeGen/denormalfpmode-f32.c
21 ↗(On Diff #418865)

This CHECK-LABEL is broken since you don't use CHECK, but it also isn't really necessary with only one function

This revision is now accepted and ready to land.Apr 18 2022, 1:33 PM
This revision was automatically updated to reflect the committed changes.