This is an archive of the discontinued LLVM Phabricator instance.

[TypePromotion] Don't insert Truncate for a no-op ZExt
ClosedPublic

Authored by avieira on Aug 9 2022, 4:55 AM.

Details

Summary

Hi,

As the title says, I don't believe there's a point in inserting Truncates before ZExt's that have no-effect, i.e. ZExts where the argument's type width is the same as the result's type width.

This is a prerequisite for the test in D111237 to pass.

Diff Detail

Event Timeline

avieira created this revision.Aug 9 2022, 4:55 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 9 2022, 4:55 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
avieira requested review of this revision.Aug 9 2022, 4:55 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 9 2022, 4:55 AM
samparker accepted this revision.Aug 9 2022, 6:43 AM

Thanks.

This revision is now accepted and ready to land.Aug 9 2022, 6:43 AM
avieira added a comment.EditedAug 10 2022, 3:06 AM

I'm just gonna rebase this to see if I also get the failure on TypePromotion/ARM/calls.ll that the bot is reporting.

avieira updated this revision to Diff 451435.Aug 10 2022, 6:21 AM

I had forgotten to build for ARM too, which had similar testisms as AArch64 where this patch removes unnecessary Truncates. Updated tests.

samparker accepted this revision.Aug 10 2022, 7:04 AM

Good catch.

barannikov88 added inline comments.
llvm/lib/CodeGen/TypePromotion.cpp
554

The comment is kind of misleading. According to LangRef, the size of the input operand of zext must be less than the size of the output operand. It is also asserted in the constructor of the operation (see CastInst::castIsValid).

avieira updated this revision to Diff 451509.Aug 10 2022, 8:55 AM

Is that somewhat clearer? I suspect the reason we never see a failure is because we 'replace' the input, rather than create a new ZExt. But like I said in the comment, it get's deleted. And as it is the trunc would just stay there dangling and get in the way of things.

barannikov88 accepted this revision.Aug 10 2022, 3:05 PM

Is that somewhat clearer? I suspect the reason we never see a failure is because we 'replace' the input, rather than create a new ZExt. But like I said in the comment, it get's deleted. And as it is the trunc would just stay there dangling and get in the way of things.

With that comment is is pretty much clear now, thanks.

This revision was automatically updated to reflect the committed changes.
avieira marked an inline comment as done.