This is an archive of the discontinued LLVM Phabricator instance.

[RISCV][MC] Add support for experimental zfa extension(FLI instruction not included)
ClosedPublic

Authored by joshua-arch1 on Jan 17 2023, 6:31 PM.

Details

Summary

This implements experimental support for the RISCV Zfa extension as specified here: https://github.com/riscv/riscv-isa-manual/releases/download/draft-20221119-5234c63/riscv-spec.pdf, Ch. 25. This extension has not been ratified. Once ratified, it'll move out of experimental status.

This change only adds assembly support for instructions except load-immediate instructions (fli.s/fli.d/fli.h).

Diff Detail

Event Timeline

joshua-arch1 created this revision.Jan 17 2023, 6:31 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 17 2023, 6:31 PM
joshua-arch1 requested review of this revision.Jan 17 2023, 6:31 PM

Please update llvm/docs/RISCVUsage.rst

craig.topper added inline comments.Jan 17 2023, 9:18 PM
llvm/lib/Target/RISCV/RISCVInstrInfoZfa.td
11

The spec says 0.1 I think.

32

I don't think you want to pass FINX here. That will create additional versions that use GPR has registers like Zfinx.

I think you should use FPALU_rr instead.

Similar issues exist for other instructions.

llvm/test/MC/RISCV/rv32zfa-only-valid.s
2

Please add -invalid tests as well to make sure these instructions are not accepted without Zfa.

joshua-arch1 marked 2 inline comments as done.
craig.topper added inline comments.Jan 28 2023, 10:04 PM
llvm/lib/Target/RISCV/RISCVInstrInfoZfa.td
50

We need to only allow rtz for the rounding mode for fcvtmod.w.d.

craig.topper added inline comments.Jan 29 2023, 11:20 PM
llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
538 ↗(On Diff #493208)

Please revisit this. I rewrote how isFRMArg works in D142833

joshua-arch1 marked an inline comment as done.

Drive by comment only, deferring to @craig.topper for most of this.

llvm/docs/RISCVUsage.rst
160 ↗(On Diff #493265)

...implements a subset of the...

(i.e. give a clue the implementation is not complete)

joshua-arch1 marked an inline comment as done.
craig.topper added inline comments.Jan 31 2023, 1:04 PM
llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
1859 ↗(On Diff #493462)

Can we reuse parseFRMArg and check the value in isRTZArg()? Add a DiagnosticType to RTZArg and diagnose in RISCVAsmParser::MatchAndEmitInstruction

llvm/test/MC/RISCV/rv32zfa-valid.s
39

Need tests that the "dyn" argument is optional. This used to require InstAliases to be added to the .td file, but in the last 24 hours I modified FRMArg to be an Optional operand. See D142959

Please remove the [n/4] and links to other revisions from the summary, that's what the related revisions feature is for (that I just fixed up for you, as it's a pain not to have that and be able to see at a glance what the dependencies are).

Sidenote: I don't see a [4/4] patch?...

joshua-arch1 edited the summary of this revision. (Show Details)
joshua-arch1 marked an inline comment as done.
reames added a comment.Feb 2 2023, 2:15 PM

A collection of minor comments. I did not closely examine the binary encodings.

This review is missing changes to:
clang/test/Preprocessor/riscv-target-features.c
test/CodeGen/RISCV/attributes.ll
test/MC/RISCV/attribute-arch.s

(These are just boilerplate for the new extension name.)

llvm/lib/Target/RISCV/RISCVInstrInfo.td
1868

Alphabetical please.

llvm/lib/Target/RISCV/RISCVInstrInfoZfa.td
59

This is a purely optional comment.

You have the instructions grouped by data type. It would make the definitions easier to follow if you instead grouped by instruction name. This would involve slightly more predicate scopes, but would more directly match the wording in the specification.

67

All of these are under Zfa, you can use an outer scope for this and an inner scope for the floating point extensions.

llvm/test/MC/RISCV/rv32zfa-valid.s
2

This file should be zfa-valid.s (i.e. remove the rv32) since it tests both rv32 and rv64.

47

If I'm reading the spec correctly, other rounding modes are valid on this instruction right? If so, would you mind adding at least one other rounding mode example? There's another instruction in this own set where only rtz is valid, and having a test which clearly distinguishes them would help readability.

111

We need a zfa-invalid.s example here with a different rounding mode. (Since this instruction only allows rtz).

craig.topper added inline comments.Feb 2 2023, 2:22 PM
llvm/lib/Target/RISCV/RISCVInstrInfoZfa.td
59

I've been wondering if it makes sense to have this file at all or should we fold the instructions into the Zfh, F, and D files?

reames added inline comments.Feb 2 2023, 2:43 PM
llvm/lib/Target/RISCV/RISCVInstrInfoZfa.td
59

Either would be reasonable. Happy to defer to @craig.topper 's judgement here.

joshua-arch1 marked an inline comment as done.
craig.topper added inline comments.Feb 2 2023, 7:56 PM
llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
1859 ↗(On Diff #493462)

This only seems to have been partially done?

joshua-arch1 marked 3 inline comments as done.Feb 5 2023, 10:59 PM

Ping.

llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
1859 ↗(On Diff #493462)

I think if we reuse parseFRMArg and check the value in isRTZArg(), the code quantity will be larger, since we need to add extra logic in isRTZArg() like what you did in initial isFRMArg() implementation.

1859 ↗(On Diff #493462)

Since we have moved FRM parsing to a custom operand parser, it's briefer and more consistent to check all types of FRM operands in operand parsers instead of in isFRMArg()/isRTZArg().

1859 ↗(On Diff #493462)

This only seems to have been partially done?

Did you mean 'reuse parseFRMArg and check the value in isRTZArg()'? I didn't do that. You can check my reply to your last comment.

craig.topper added inline comments.Feb 5 2023, 11:11 PM
llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
1859 ↗(On Diff #493462)

Yes.

We can use parseFRMArg for parsing. And in isRTZArg() check `isFRMArg() && FRM.FRM == RISCVFPRndMode::RTZ;'

joshua-arch1 marked 7 inline comments as done.
joshua-arch1 marked an inline comment as done.Feb 7 2023, 5:31 PM

Ping.

craig.topper accepted this revision.Feb 7 2023, 6:00 PM
This comment was removed by craig.topper.
This revision is now accepted and ready to land.Feb 7 2023, 6:00 PM
craig.topper requested changes to this revision.Feb 7 2023, 6:03 PM
craig.topper added inline comments.
llvm/lib/Target/RISCV/RISCVInstrInfoZfa.td
68

Lists in nested let statements don't concatenate. This list needs to be [HasStdExtD, HasStdExtZfa]

This revision now requires changes to proceed.Feb 7 2023, 6:03 PM
craig.topper added inline comments.Feb 7 2023, 6:05 PM
llvm/test/MC/RISCV/zfa-valid.s
12 ↗(On Diff #495018)

Please add a CHECK-NO-EXT RUN like some of the other tests to make sure the predicates are correct.

Ping.

llvm/lib/Target/RISCV/RISCVInstrInfoZfa.td
68

So I'm wondering if we should use nested format as @reames mentioned in the last comment. I guess lists in order will be better.

craig.topper added inline comments.Feb 8 2023, 11:45 PM
llvm/lib/Target/RISCV/RISCVInstrInfoZfa.td
68

Yeah lists in order will be better.

craig.topper added inline comments.Feb 8 2023, 11:51 PM
llvm/test/MC/RISCV/rv32zfa-only-valid.s
7

Add CHECK-NO-EXT here too

llvm/test/MC/RISCV/zfa-valid.s
12 ↗(On Diff #495759)

If we remove the +d and +zfh here do we get error messages that mention all of the required extensions? I want to make sure we check that the .h instructions require zfh and zfa. Same for .d

joshua-arch1 marked 2 inline comments as done.
This revision is now accepted and ready to land.Feb 9 2023, 10:40 AM
asb accepted this revision.Feb 9 2023, 10:54 AM
asb added inline comments.
llvm/lib/Target/RISCV/RISCVInstrInfoZfa.td
59

No strong opinion for on keeping this separate or merging into another file. At least for the G extensions, the instruction definitions are in the order they're listed in the RV32/64G Instruction Set Listings table, on the basis this makes it easier to check at a glance if the right encodings are used. Sadly a similar table doesn't seem to exist in the documentation for Zfa.

@joshua-arch1 do you have commit access or do you need me to merge this?

joshua-arch1 marked 4 inline comments as done.Feb 14 2023, 1:30 AM

@joshua-arch1 do you have commit access or do you need me to merge this?

I have no access yet. Could you please help merge this?

@joshua-arch1 do you have commit access or do you need me to merge this?

I have no access yet. Could you please help merge this?

I have been granted commit access recently and I merged this patch just now.

@joshua-arch1 do you have commit access or do you need me to merge this?

I have no access yet. Could you please help merge this?

I have been granted commit access recently and I merged this patch just now.

I just checked, and I do *not* see this change in tree. Did you forget to push? Or merge to the wrong repo?

This revision was landed with ongoing or failed builds.Feb 16 2023, 8:09 AM
This revision was automatically updated to reflect the committed changes.

This was initially landed in two commits without proper commit messages. I reverted both and relanded the change this morning.

Original commits:

commit 321cd52ba2647259f58b0d38cdb62528a9ded9a1
Author: Jun Sha (Joshua) <cooper.joshua@linux.alibaba.com>
Date: Thu Feb 16 09:54:40 2023 +0800

Update: [RISCV][MC] Add support for experimental zfa extension(FLI instruction not included)

commit 54c136e6c630966255293d42c882eab116437834
Author: Jun Sha (Joshua) <cooper.joshua@linux.alibaba.com>
Date: Thu Feb 16 09:50:59 2023 +0800

[RISCV][MC] Add support for experimental zfa extension(FLI instruction not included)

Seeing buildbot failures, which look valid. Example:
https://lab.llvm.org/buildbot#builders/196/builds/26601

This caused me to look more closely at the change, and we are definitely missing things which should be enabled by such an extension change. One specific example is that we failed to add zfa in SupportedExperimentalExtensions.

Oddly, I do not see this failure locally. I don't have a good explanation for that.

I'm about to revert.

Oddly, I do not see this failure locally. I don't have a good explanation for that.

I chatted w/ @craig.topper, and he confirmed that this didn't reproduce locally for him either. Neither of us have a good explanation of why right now. I need to run for the moment, but plan to return to this later in the day to see if we can get this straightened out.

My guess earlier about RISCVISAInfo.cpp is probably not the issue. Craig mentioned that the llvm-mc feature detection should be driven from tablegen, which this change did include.

reames reopened this revision.Feb 16 2023, 1:05 PM
This revision is now accepted and ready to land.Feb 16 2023, 1:05 PM