This is an archive of the discontinued LLVM Phabricator instance.

[RISCV] Add way to mark CompressPats that should only be used for compressing.
ClosedPublic

Authored by craig.topper on Jan 17 2021, 9:15 PM.

Details

Summary

There can be muliple patterns that map to the same compressed
instruction. Reversing those leads to multiple ways to uncompress
an instruction, but its not easily controllable which one will
be chosen by the tablegen backend.

This patch adds a flag to mark patterns that should only be used
for compressing. This allows us to leave one canonical pattern
for uncompressing.

The obvious benefit of this is getting c.mv to uncompress to
the addi patern that is aliased to the mv pseudoinstruction. For
the add/and/or/xor/li patterns it just removes some unreachable
code from the generated code.

Diff Detail

Event Timeline

craig.topper created this revision.Jan 17 2021, 9:15 PM
craig.topper requested review of this revision.Jan 17 2021, 9:15 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 17 2021, 9:15 PM
Herald added a subscriber: MaskRay. · View Herald Transcript

Add test updates

My instinct is this should be a priority to match InstAlias; is there ever any overlap?

My instinct is this should be a priority to match InstAlias; is there ever any overlap?

After this patch, uncompressing is a 1:1 mapping. In the compress direction there are multiple patterns that map to the same sequence. There are also multiple patterns that start from ADD for example. Overlaps seem to be handled by Register classes like GPRNoX0 and by immediate predicates. If a priority is needed, I believe it would be needed in the compress direction, not the uncompress direction.

My instinct is this should be a priority to match InstAlias; is there ever any overlap?

After this patch, uncompressing is a 1:1 mapping. In the compress direction there are multiple patterns that map to the same sequence. There are also multiple patterns that start from ADD for example. Overlaps seem to be handled by Register classes like GPRNoX0 and by immediate predicates. If a priority is needed, I believe it would be needed in the compress direction, not the uncompress direction.

Right, yes, which corresponds to the InstAlias direction that corresponds to the priority (InstAlias, at least to me, is conceptually the other way round to CompressPat). I wasn't particularly thinking; decompression is of course a (total) function, that's how a lot of cores implement decoding compressed instructions.

My instinct is this should be a priority to match InstAlias; is there ever any overlap?

After this patch, uncompressing is a 1:1 mapping. In the compress direction there are multiple patterns that map to the same sequence. There are also multiple patterns that start from ADD for example. Overlaps seem to be handled by Register classes like GPRNoX0 and by immediate predicates. If a priority is needed, I believe it would be needed in the compress direction, not the uncompress direction.

Right, yes, which corresponds to the InstAlias direction that corresponds to the priority (InstAlias, at least to me, is conceptually the other way round to CompressPat). I wasn't particularly thinking; decompression is of course a (total) function, that's how a lot of cores implement decoding compressed instructions.

So are you ok with this patch as is?

My instinct is this should be a priority to match InstAlias; is there ever any overlap?

After this patch, uncompressing is a 1:1 mapping. In the compress direction there are multiple patterns that map to the same sequence. There are also multiple patterns that start from ADD for example. Overlaps seem to be handled by Register classes like GPRNoX0 and by immediate predicates. If a priority is needed, I believe it would be needed in the compress direction, not the uncompress direction.

Right, yes, which corresponds to the InstAlias direction that corresponds to the priority (InstAlias, at least to me, is conceptually the other way round to CompressPat). I wasn't particularly thinking; decompression is of course a (total) function, that's how a lot of cores implement decoding compressed instructions.

So are you ok with this patch as is?

Sorry, yes, didn't realise I hadn't made myself clear.

frasercrmck added inline comments.Jan 19 2021, 1:49 AM
llvm/lib/Target/RISCV/RISCVInstrInfoC.td
904

Is there a reason why this is true but the others are 1?

craig.topper added inline comments.Jan 19 2021, 4:48 AM
llvm/lib/Target/RISCV/RISCVInstrInfoC.td
904

I think I wrote this one first and forced myself to use true. I made sure it worked then came back and did the others. I guess I fell back into not expecting true/false in tablegen.

Consistently use isCompressOnly = true

This revision is now accepted and ready to land.Jan 19 2021, 11:26 PM