This is an archive of the discontinued LLVM Phabricator instance.

[clang][RISCV] Set vscale_range attribute based on VLEN
ClosedPublic

Authored by reames on Oct 17 2022, 12:58 PM.

Details

Summary

Follow up on D135894, restructure code to work in terms of minimum and maximum VLEN coming from RISCVISAInfo.cpp. In the original review, I'd mentioned that MinVLEN was sometimes zero. This turns out to be a case of human error, combined with really bad (lack of) error reporting.

This patch adds appropriate tests for various vector extension combinations to show the mechanism works, but doesn't try to provide exhaustive coverage of the extension interactions. Presumably, that is already covered in existing tests elsewhere.

Diff Detail

Event Timeline

reames created this revision.Oct 17 2022, 12:58 PM
reames requested review of this revision.Oct 17 2022, 12:58 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptOct 17 2022, 12:58 PM

In the original review, I'd mentioned that MinVLEN was sometimes zero. That's still true, but apparently only happens if you specify multiple extensions in the -target_feature string. So, we can at least test "v" and "zve64x" on their own before I go figure out exactly what's going wrong regarding e.g. parsing "+v,+zvl512b".

I think you need to use `-target-feature "v" -target-feature "zvl512b".

In the original review, I'd mentioned that MinVLEN was sometimes zero. That's still true, but apparently only happens if you specify multiple extensions in the -target_feature string. So, we can at least test "v" and "zve64x" on their own before I go figure out exactly what's going wrong regarding e.g. parsing "+v,+zvl512b".

I think you need to use `-target-feature "v" -target-feature "zvl512b".

So, this was part right. The other issue is I'd been using Zvl512b, and apparently this bit of parsing code is case sensitive. I'm going to look into improving the error reporting here.

reames updated this revision to Diff 468344.Oct 17 2022, 3:11 PM
reames edited the summary of this revision. (Show Details)
This revision is now accepted and ready to land.Oct 18 2022, 2:00 AM
This revision was landed with ongoing or failed builds.Oct 19 2022, 4:15 PM
This revision was automatically updated to reflect the committed changes.

In the original review, I'd mentioned that MinVLEN was sometimes zero. That's still true, but apparently only happens if you specify multiple extensions in the -target_feature string. So, we can at least test "v" and "zve64x" on their own before I go figure out exactly what's going wrong regarding e.g. parsing "+v,+zvl512b".

I think you need to use `-target-feature "v" -target-feature "zvl512b".

So, this was part right. The other issue is I'd been using Zvl512b, and apparently this bit of parsing code is case sensitive. I'm going to look into improving the error reporting here.

Replying back to myself here as I'm not quite sure where to put this...

So, it turns out target-feature is currently quite weird. At the *clang* level, we require individual target-feature options for each extensions. Using a compound "+v,+zvl512b" is not recognized by the clang code (i.e, the bit this patch was modifying). However, this raw string gets joined with the valid attributes, and set into the IR as "target-features"="+64bit,+v,+zvl512b" on the function. This string is then parsed by later consumers, and thus the extensions listed in the compound list *are* picked up during e.g. codegen. So, it turns out we both do, and don't, parse these compound target-feature strings.

I'm leaning in the direction of having clang just support the compound target-feature strings, but I haven't found the right place for that just yet.