This is an archive of the discontinued LLVM Phabricator instance.

[DAGCombine] Do not remove masking argument to FP16_TO_FP for some targets
ClosedPublic

Authored by nemanjai on Feb 8 2021, 11:11 AM.

Details

Summary

As of commit 284f2bffc9bc5, the DAG Combiner gets rid of the masking of the input to this node if the mask only keeps the bottom 16 bits. This is because the underlying library function does not use the high order bits. However, on PowerPC's ELFv2 ABI, it is the caller that is responsible for clearing the bits from the register. Therefore, the library implementation of __gnu_h2f_ieee will return an incorrect result if the bits aren't cleared.

This combine is desired for ARM (and possibly other targets) so this patch adds a query to Target Lowering to check if this zeroing needs to be kept.

I am hoping to be able to get this reviewed, updated if needed and merge the fix into 12.0.

Fixes: https://bugs.llvm.org/show_bug.cgi?id=49092

Diff Detail

Event Timeline

nemanjai created this revision.Feb 8 2021, 11:11 AM
nemanjai requested review of this revision.Feb 8 2021, 11:11 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 8 2021, 11:11 AM

We already seem to have shouldSignExtendTypeInLibCall (used in the actual ExpandLibCall this code gets to) and shouldExtendTypeInLibCall (used in another expander I didn't know about). Ideally that's where we'd fix this issue by getting the generic call lowerer to insert a zext (which may be folded again later, if it's a sound transformation). Unfortunately because we only have an i32 when the expansion happens I don't think that's possible.

But this seems like a much more targetted fix that only applies to this one f16 conversion so the name should probably reflect that.

nemanjai updated this revision to Diff 322326.Feb 9 2021, 3:02 AM

Correct the formatting and change the name to reflect this is for the half precision conversion libcall.

t.p.northover accepted this revision.Feb 9 2021, 3:06 AM

Thanks. I think this looks like the best fix we can do now.

This revision is now accepted and ready to land.Feb 9 2021, 3:06 AM

We already seem to have shouldSignExtendTypeInLibCall (used in the actual ExpandLibCall this code gets to) and shouldExtendTypeInLibCall (used in another expander I didn't know about). Ideally that's where we'd fix this issue by getting the generic call lowerer to insert a zext (which may be folded again later, if it's a sound transformation). Unfortunately because we only have an i32 when the expansion happens I don't think that's possible.

My initial thought was along these lines. In fact, I tried to do this in the PPC call lowering but no information exists at that point that this should be a 16-bit value. This would kind of require that I use the name of the function or something similarly flaky which I don't find acceptable. Ultimately, the combine is quite specific (the masking of arguments to normal calls is not removed) so the fix had to be quite specific.

But this seems like a much more targetted fix that only applies to this one f16 conversion so the name should probably reflect that.

Updated the name. My initial thought was to make it a somewhat generic name in case this is useful for other similar transformations in the future.

Thanks. I think this looks like the best fix we can do now.

Thank you so much for the quick review Tim.

This revision was landed with ongoing or failed builds.Feb 9 2021, 4:37 AM
This revision was automatically updated to reflect the committed changes.
vchuravy added a project: Restricted Project.Feb 16 2021, 7:27 PM