This is an archive of the discontinued LLVM Phabricator instance.

[RISCV] Add a bit to TSFlags to mark SignExtendingOpW instructions for SExtWRemoval.
ClosedPublic

Authored by craig.topper on Dec 13 2022, 1:01 PM.

Details

Summary

Instead of switching on the opcode in SExtWRemoval, we can use a
bit in TSFlags. This reduces the amount of code that needs to be
generated to implement the switch. The opcodes are scattered throughout
the opcode enum, so the switch isn't very densely packed.

Diff Detail

Event Timeline

craig.topper created this revision.Dec 13 2022, 1:01 PM
craig.topper requested review of this revision.Dec 13 2022, 1:01 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 13 2022, 1:01 PM
asb added inline comments.Dec 14 2022, 7:57 AM
llvm/lib/Target/RISCV/MCTargetDesc/RISCVBaseInfo.h
100

Line wrapping related error? Should be "Used by SextWRemoval." too?

It would be nice to maintain a version of the comment from RISCVSExtWRemoval.cpp too. e.g. "Some instructions with this flag aren't W instructions, but are either sign extended from a smaller size, always outputs a small integer, or put zeros in bits 63:31."

llvm/lib/Target/RISCV/RISCVInstrFormats.td
209

"Used by"

Address @asb's comments

asb accepted this revision.Dec 14 2022, 10:19 AM

LGTM!

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

Just curious, what was the motivation here? The resulting code appears much less clear to me.

If this was a compile time issue, did you consider using e.g. a denseset membership test instead?

Just curious, what was the motivation here? The resulting code appears much less clear to me.

If this was a compile time issue, did you consider using e.g. a denseset membership test instead?

I figured W instructions were such a common property of RISC-V that it made sense to declare them at the instruction declaration rather than maintaining them in an adhoc list. Do you think the whole thing is less clear or the ones that aren't really W instructions?

asb added a comment.Dec 14 2022, 11:44 AM

Just curious, what was the motivation here? The resulting code appears much less clear to me.

If this was a compile time issue, did you consider using e.g. a denseset membership test instead?

From my perspective it's really a style / taste issue (and to be honest when reviewing the patch I hadn't considered much that some might prefer the old way). Is it clearer to mark these instruction properties in tablegen where the instructions are defined, or in a separate helper function. In general I like the tablegen property approach, particularly if it's plausible the flag might be queried from multiple places in the future. But I don't feel overly strongly on this.

On a purely stylistic view, I prefer having the information localized in one place. It's much easier to see the code for the transform and figure out what it does if the scope is small. The tablegen approach requires looking at a lot more code to understand the total interaction.

Given both Alex and Craig prefer the tablegen style, I'll consider myself outvoted. I don't care strongly about it.