This is an archive of the discontinued LLVM Phabricator instance.

[RISCV][Clang] Add -mno-div option to disable hardware int division
Needs ReviewPublic

Authored by ksyx on May 20 2021, 3:56 AM.

Details

Summary

With option -mno-div, hardware integral division and modulus instructions in M extension will be disabled, while leaving multiply instructions enabled.

I am not sure whether there is a better way of implementing this, so please point out if there is one, thanks.

Reference: riscv-toolchain-conventions

Diff Detail

Event Timeline

ksyx created this revision.May 20 2021, 3:56 AM
ksyx requested review of this revision.May 20 2021, 3:56 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptMay 20 2021, 3:56 AM

Isn't the gcc name for this -mno-div? Should we be consistent?

clang/lib/Basic/Targets/RISCV.cpp
154

Does gcc also have this define? Why do we need this in addition to not defining __riscv_div.

llvm/lib/Target/RISCV/RISCVISelLowering.cpp
223–224

These MUL lines are affected by the disableHardwareIntDiv above. Please split mul and div handling apart.

I continue to believe this kind of thing is a bad idea (missing fsqrt for F is another one). M means mul and div, if your hardware lacks div then it's not compliant with the spec. M-mode is free to lie to S-mode and above as to what's supported by the hardware and emulate as needed, but if misa.M is 1 then div must work.

ksyx added a comment.May 22 2021, 10:28 PM

Isn't the gcc name for this -mno-div? Should we be consistent?

I am not sure whether using -mno-div might bring in some confusion since from the name no-div itself it expresses a sense of excluding all hardware division instructions, both float ones and integral ones, from my personal understanding. However, as in the documentation, it only affects the integral ones and float one was controlled by another. Thus for the clearance I used this naming.

I have not much understanding about what compatibility with GCC we need to achieve but I am okay with both kinds of naming and changing this is totally ok if required.

clang/lib/Basic/Targets/RISCV.cpp
154

Ok. I will remove it.

ksyx updated this revision to Diff 347603.May 25 2021, 3:54 AM
ksyx marked 2 inline comments as done.
ksyx retitled this revision from [RISCV][Clang] Add -mno-idiv option to disable hardware int division to [RISCV][Clang] Add -mno-div option to disable hardware int division.
ksyx edited the summary of this revision. (Show Details)
ksyx added a reviewer: craig.topper.
  • remove redundant macro definition
  • split mul and div handling in RISCVISelLowering.cpp
  • rename no-idiv into no-div
ksyx updated this revision to Diff 347637.May 25 2021, 4:50 AM

fix: indent

luismarques added inline comments.May 26 2021, 9:56 AM
clang/include/clang/Driver/Options.td
3149–3152

Remove the redundant "hardware".

BTW, is "integral" actually correct, or should it be "integer division"?

clang/lib/Basic/Targets/RISCV.h
49

DisableHardwareIntDiv -> DisableIntDiv

Also, in general it would be best for the feature to be positive rather than negative, but I'm not sure whether it makes sense to make an exception here, since the option that toggles the feature is also negative.

clang/test/Driver/riscv-no-div.c
1–17

Is not FileCheck the only way to check these do not occur?

33–35

Should we be checking the actual instructions in a Clang test?

llvm/test/CodeGen/RISCV/no-div.ll
29–31

I'm not sure it makes sense to refer to the possibility of the compilation failing. It's just that we shouldn't emit divide instructions.

34–44

@jrtc27 should we use update_llc_test_checks.py instead here?

We have Zmmul extension in the ISA spec now, that's equivalent to -mno-div , so I suggest we should go forward to implement that extension rather than -mno-div.

https://github.com/riscv/riscv-isa-manual/pull/648

We have Zmmul extension in the ISA spec now, that's equivalent to -mno-div , so I suggest we should go forward to implement that extension rather than -mno-div.

https://github.com/riscv/riscv-isa-manual/pull/648

Yes, if people want subsets of extensions, that's the way to do it.

We have Zmmul extension in the ISA spec now, that's equivalent to -mno-div , so I suggest we should go forward to implement that extension rather than -mno-div.
https://github.com/riscv/riscv-isa-manual/pull/648

Thanks for bringing that to our attention, Kito. I had missed that recent PR and its discussion.
If the GNU ecosystem intends to move away from -mno-div soonish then Zmmul is for sure the way to go. I don't see enough benefit for LLVM to add a stop-gap compatibility option.

ksyx added a comment.May 26 2021, 5:41 PM

So it seems the better way to do this would definitely by adding a subextension as the spec had changed. But I'd like also to ask how will GCC deal with this option, and should we make this option an alias to turn off M extension and turn on ZMMul extension?

So it seems the better way to do this would definitely by adding a subextension as the spec had changed. But I'd like also to ask how will GCC deal with this option, and should we make this option an alias to turn off M extension and turn on ZMMul extension?

Regarding "turn off M extension", see Krste's comment in the PR:

I think -mno-div is OK as a compiler option, but it's meaning is for the compiler not to generate divide instructions, not to indicate what the ISA is. So for example, -mno-div should not set ELF flags in binary to indicate ISA doesn't have divide - it should simply not generate divide instructions.

ksyx updated this revision to Diff 348206.May 27 2021, 3:32 AM
ksyx marked an inline comment as done.
ksyx edited the summary of this revision. (Show Details)

Implemented Zmmul subextension, and let no-div to be using this subextension instead of M itself.

ksyx marked 2 inline comments as done.May 27 2021, 3:34 AM
ksyx added a comment.May 27 2021, 3:40 AM

So it seems the better way to do this would definitely by adding a subextension as the spec had changed. But I'd like also to ask how will GCC deal with this option, and should we make this option an alias to turn off M extension and turn on ZMMul extension?

Regarding "turn off M extension", see Krste's comment in the PR:

I think -mno-div is OK as a compiler option, but it's meaning is for the compiler not to generate divide instructions, not to indicate what the ISA is. So for example, -mno-div should not set ELF flags in binary to indicate ISA doesn't have divide - it should simply not generate divide instructions.

Thanks for mentioning that! Now, I changed the effect of no-div option into choosing a proper extension and implemented the Zmmul subextension. Is this solution acceptable or are there anything need further changes?

Thanks for mentioning that! Now, I changed the effect of no-div option into choosing a proper extension and implemented the Zmmul subextension. Is this solution acceptable or are there anything need further changes?

It seems like the community is quickly converging on just using the ISA string with Zmmul, and not using no-div. While being compatible with the GNU tools is nice, if they are planning on dropping support for no-div soonish then we probably shouldn't add support for it. IMO, Zmmul should be a separate patch and presumably (at the moment) be gated by -menable-experimental-extensions.

Personally I prefer to deprecate -mno-div soon, but based on the rule for RISC-V GNU toolchain, it need to wait Zmmul extension frozen.
My plan is deprecate the -mno-div and emit warning to tell user should use Zmmul instead once it frozen.

asb added a comment.May 27 2021, 7:46 AM

Personally I prefer to deprecate -mno-div soon, but based on the rule for RISC-V GNU toolchain, it need to wait Zmmul extension frozen.
My plan is deprecate the -mno-div and emit warning to tell user should use Zmmul instead once it frozen.

Thanks for clarifying Kito. In that case, I think having clang support -mno-div in order to match the GNU toolchain makes sense, and we can later follow GCC in deprecating it if they do. Given how long it can take to ratify extensions, I'm wary of making assumptions about when zmmul may be ratified.

ksyx added a comment.May 27 2021, 5:24 PM

Thanks for mentioning that! Now, I changed the effect of no-div option into choosing a proper extension and implemented the Zmmul subextension. Is this solution acceptable or are there anything need further changes?

It seems like the community is quickly converging on just using the ISA string with Zmmul, and not using no-div. While being compatible with the GNU tools is nice, if they are planning on dropping support for no-div soonish then we probably shouldn't add support for it. IMO, Zmmul should be a separate patch and presumably (at the moment) be gated by -menable-experimental-extensions.

Thanks for the news and I think having experimental-zmmul a separate patch is a good idea. But which implementation of no-div is better, the one that chooses extension between M and zmmul or the one that simply being an attribute like Diff 3, or are there any other suggestions?

ksyx updated this revision to Diff 348525.May 28 2021, 7:31 AM

split Zmmul implementation and -mno-div implementation