Page MenuHomePhabricator

[RISCV] Add SiFive-VIU75 for llvm

Authored by arcbbb on Mar 8 2021, 11:02 PM.



This patch adds support for the SiFive CPU VIU75.

details of the CPU can be found here:

Diff Detail

Unit TestsFailed

130 msx64 windows > lld.MachO::function-starts.s
Script: -- : 'RUN: at line 3'; split-file C:\ws\w1\llvm-project\premerge-checks\lld\test\MachO\function-starts.s C:\ws\w1\llvm-project\premerge-checks\build\tools\lld\test\MachO\Output\function-starts.s.tmp

Event Timeline

arcbbb created this revision.Mar 8 2021, 11:02 PM
arcbbb requested review of this revision.Mar 8 2021, 11:02 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 8 2021, 11:02 PM
jrtc27 requested changes to this revision.Mar 9 2021, 7:35 AM
jrtc27 added inline comments.

I don't think we should ever enable V and related extensions here for two reasons:

  1. They're currently experimental, so -mcpu=sifive-viu75 bypasses -menable-experimental-extensions.
  1. They're still drafts that are going to see changes and we don't maintain backwards compatibility between draft revisions, so as soon as there's a new draft spec we'll have to remove these extensions from this model as the core will no longer implement the spec version we do.
This revision now requires changes to proceed.Mar 9 2021, 7:35 AM
khchen added inline comments.Mar 10 2021, 5:14 PM

They're currently experimental, so -mcpu=sifive-viu75 bypasses -menable-experimental-extensions.

I think maybe we could find a way to force users to give -menable-experimental-extensions in llc when they use a cpu which has experimental features, it will be acceptable for me.

or maybe the cpu naming should be -mcput=experimental-sifive-viu75 like -mattr=+experimental-v?

I think we can hold this for the time being until it is ratified or no longer experimental.

asb added inline comments.Mar 18 2021, 4:01 AM

I agree, if there's a desire to enable the unratified V extensions that's a discussion to be had with the wider LLVM community. It would be unfortunate if shipping devices ended up supporting unratified extension versions that don't match the ratified version, adding extra burden in terms of compiler support.

It may make sense for LLVM to support this (where there are users and people willing to maintain support), but we'd want an llvm-dev discussion about what kind of precedent it sets, expectations in ongoing support etc.

arcbbb abandoned this revision.May 6 2021, 11:38 PM

Thank you for all the suggestions.

It does require a discussion to draw the line when supporting a device with an unratified extension.
I abandon it because now it is deprecated.