This is an archive of the discontinued LLVM Phabricator instance.

[GlobalISel] Change widenScalar of G_FCONSTANT to mutate into G_CONSTANT.
ClosedPublic

Authored by aemerson on Jul 14 2022, 1:49 AM.

Details

Summary

Widening a G_FCONSTANT by extending and then generating G_FPTRUNC doesn't produce the same result all the time. Instead, we can just transform it to a G_CONSTANT of the same bit pattern and truncate using a plain G_TRUNC instead.

Fixes https://github.com/llvm/llvm-project/issues/56454

Diff Detail

Event Timeline

aemerson created this revision.Jul 14 2022, 1:49 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 14 2022, 1:49 AM
aemerson requested review of this revision.Jul 14 2022, 1:49 AM
foad added a comment.Jul 14 2022, 2:04 AM

Widening a G_FCONSTANT by extending and then generating G_FPTRUNC doesn't produce the same result all the time.

That's only a problem if you care about the bit pattern of NaNs, right? It should be OK for all non-NaN values.

Widening a G_FCONSTANT by extending and then generating G_FPTRUNC doesn't produce the same result all the time.

That's only a problem if you care about the bit pattern of NaNs, right? It should be OK for all non-NaN values.

Yeah, but it seems better to handle this as a G_CONSTANT rather than have value dependent legalization.

foad added a comment.Jul 14 2022, 2:25 AM

Widening a G_FCONSTANT by extending and then generating G_FPTRUNC doesn't produce the same result all the time.

That's only a problem if you care about the bit pattern of NaNs, right? It should be OK for all non-NaN values.

Yeah, but it seems better to handle this as a G_CONSTANT rather than have value dependent legalization.

Agreed, I wasn't suggesting to change anything, just trying to understand what the problem was.

I don't really understand why we have G_FCONSTANT in the first place. Also I don't really understand the concept of legalizing a constant.

Widening a G_FCONSTANT by extending and then generating G_FPTRUNC doesn't produce the same result all the time.

That's only a problem if you care about the bit pattern of NaNs, right? It should be OK for all non-NaN values.

Yeah, but it seems better to handle this as a G_CONSTANT rather than have value dependent legalization.

Agreed, I wasn't suggesting to change anything, just trying to understand what the problem was.

I don't really understand why we have G_FCONSTANT in the first place. Also I don't really understand the concept of legalizing a constant.

It probably makes selection easier when importing patterns, so that's something that might cause some issues if we decide to remove it one day.

Could use some additional end to end tests, particularly ones that change the value (and some cases where it folds through an fpext to a legalized operation). We might be missing some constant fold code that bothers handling G_CONSTANT and G_FCONSTANT interchangeably.

aemerson updated this revision to Diff 444724.Jul 14 2022, 10:38 AM

I added a couple of tests but not exactly sure what you meant by "folds through fpext". I guess at the moment we don't have any constant folding that will transform G_FPEXT(G_CONSTANT) -> wide G_CONSTANT.

arsenm accepted this revision.Jul 14 2022, 10:39 AM

I added a couple of tests but not exactly sure what you meant by "folds through fpext". I guess at the moment we don't have any constant folding that will transform G_FPEXT(G_CONSTANT) -> wide G_CONSTANT.

Yes that's what I mean (although I guess that could turn back into G_FCONSTANT)

This revision is now accepted and ready to land.Jul 14 2022, 10:39 AM
This revision was landed with ongoing or failed builds.Jul 14 2022, 11:05 AM
This revision was automatically updated to reflect the committed changes.