This is an archive of the discontinued LLVM Phabricator instance.

[RISCV] Update V extension to v1.0-draft 08a0b464.
ClosedPublic

Authored by HsiangKai on Jan 12 2021, 10:54 PM.

Details

Summary

D93611, D93612, D93613, and D93614 have been reviewed and accepted. I change the version number of vector extension to v1.020201218, i.e., append the date of commit 08a0b464 in riscv-v-spec to v1.0.

Currently, there is no v1.0 tag in riscv-v-spec. That is why I use the date of the commit as the draft version number. We hope v1.0 could be merged into LLVM 12. I am not sure whether it is an acceptable way to do it or not.

Diff Detail

Event Timeline

HsiangKai created this revision.Jan 12 2021, 10:54 PM
HsiangKai requested review of this revision.Jan 12 2021, 10:54 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 12 2021, 10:54 PM
khchen added a subscriber: khchen.Jan 13 2021, 8:30 AM
HsiangKai updated this revision to Diff 318221.Jan 21 2021, 8:39 AM

Use v1.0 instead of strange version number. It is under -enable-experimental-extensions. So, I think it should be ok to do this.

This revision is now accepted and ready to land.Jan 21 2021, 10:35 AM

There are a lot of "Resolve for v1.0" issues open against the spec still. Are we sure we want to brand this as 1.0? It will end up as such in the ELF attributes and thus be deemed compatible with future "real" 1.0 binaries.

There are a lot of "Resolve for v1.0" issues open against the spec still. Are we sure we want to brand this as 1.0? It will end up as such in the ELF attributes and thus be deemed compatible with future "real" 1.0 binaries.

We could keep the version number as v0.9 or do you think it is better to keep it as v1.020201218.

There are a lot of "Resolve for v1.0" issues open against the spec still. Are we sure we want to brand this as 1.0? It will end up as such in the ELF attributes and thus be deemed compatible with future "real" 1.0 binaries.

We could keep the version number as v0.9 or do you think it is better to keep it as v1.020201218.

You don't want it to be higher than 1.0 either as that would be newer than the future actual 1.0.

(Their problem stems from having 1.0 drafts before they've resolved all the outstanding issues and frozen the instruction set; if they didn't jump the gun then things would be saner for people implementing it)

@jrtc27 just let you know I have same concern too, that's one major reason why we don't upstream those extension on GNU toolchain... we are intend to introduce an internal revision number on ELF attribute in near future, e.g. v-ext 0.9.1 / v0p9p1 to prevent compatible issue here.

There are a lot of "Resolve for v1.0" issues open against the spec still. Are we sure we want to brand this as 1.0? It will end up as such in the ELF attributes and thus be deemed compatible with future "real" 1.0 binaries.

We could keep the version number as v0.9 or do you think it is better to keep it as v1.020201218.

You don't want it to be higher than 1.0 either as that would be newer than the future actual 1.0.

Vector extension is under -enable-experimental-extensions in LLVM. Could we change the version number to v1.0 to align with current V specification? "Experimental v1.0" should be more consistent with "v1.0-draft" V specification. What do you think?

Could you also update macros and attributes which implemented in https://reviews.llvm.org/D94403 and https://reviews.llvm.org/D94931

Herald added a project: Restricted Project. · View Herald TranscriptJan 25 2021, 2:20 AM

Also, when the V spec becomes official, it'll be labeled v2.0. Therefore, as long as v0.9 or v1.0 is implemented, V is only available as an experimental feature.

This revision was landed with ongoing or failed builds.Jan 25 2021, 8:03 PM
This revision was automatically updated to reflect the committed changes.