Page MenuHomePhabricator

[RISCV] Add side-effect-free vsetvli intrinsics
ClosedPublic

Authored by frasercrmck on Jan 21 2022, 10:23 AM.

Details

Summary

This patch introduces new intrinsics that enable the use of vsetvli in
contexts where only the returned vector length is of interest. The
pre-existing intrinsics are marked with side-effects, which prevents
even trivial optimizations on/across them.

These intrinsics are intended to be used in situations where the vector
length is fed in turn to RVV intrinsics or to vector-predication
intrinsics during loop vectorization, for example. Those codegen paths
ensure that instructions are generated with their own implicit vsetvli,
so the vector length and vtype can be relied upon to be correct.

No corresponding C builtins are planned at this stage, though that is a
possibility for the future if the need arises.

Diff Detail

Event Timeline

frasercrmck created this revision.Jan 21 2022, 10:23 AM
frasercrmck requested review of this revision.Jan 21 2022, 10:23 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 21 2022, 10:23 AM

I apologise that opt is so uninspired a name. I'll blame it on the fact it's Friday. I'm very open to alternatives!

This revision is now accepted and ready to land.Jan 21 2022, 11:04 AM
This revision was automatically updated to reflect the committed changes.

I would prefer use that to replace existing vsetvlimax and vsetvli once we verified that, I believe vsetvl and vsetvlmax intrinsic should be no side effect on C/C++ language level.

I would prefer use that to replace existing vsetvlimax and vsetvli once we verified that, I believe vsetvl and vsetvlmax intrinsic should be no side effect on C/C++ language level.

Yes I would have preferred that too. However I spoke with Craig offline and he told me that there are users which have now come to depend on the C/C++ vsetvli/vsetvlimax builtins having side effects. So I fear that ship may have sailed? I'd definitely be up for discussing a transition path but we'd need to assess the implications and any transition path.

I would prefer use that to replace existing vsetvlimax and vsetvli once we verified that, I believe vsetvl and vsetvlmax intrinsic should be no side effect on C/C++ language level.

Yes I would have preferred that too. However I spoke with Craig offline and he told me that there are users which have now come to depend on the C/C++ vsetvli/vsetvlimax builtins having side effects. So I fear that ship may have sailed? I'd definitely be up for discussing a transition path but we'd need to assess the implications and any transition path.

The extensions were experimental until extremely recently (maybe V still is, even?); as someone not hugely involved in the vector work, if non-side-effecting intrinsics are significantly better than side-effecting ones then you should prioritise getting it right. The fallout is unfortunate but will be short-term, and we've never guaranteed any kind of stability for experimental extensions. Otherwise you'll have much more pain in the long run dealing with this legacy baggage.

I would prefer use that to replace existing vsetvlimax and vsetvli once we verified that, I believe vsetvl and vsetvlmax intrinsic should be no side effect on C/C++ language level.

Yes I would have preferred that too. However I spoke with Craig offline and he told me that there are users which have now come to depend on the C/C++ vsetvli/vsetvlimax builtins having side effects. So I fear that ship may have sailed? I'd definitely be up for discussing a transition path but we'd need to assess the implications and any transition path.

The extensions were experimental until extremely recently (maybe V still is, even?); as someone not hugely involved in the vector work, if non-side-effecting intrinsics are significantly better than side-effecting ones then you should prioritise getting it right. The fallout is unfortunate but will be short-term, and we've never guaranteed any kind of stability for experimental extensions. Otherwise you'll have much more pain in the long run dealing with this legacy baggage.

I have users who have used the side effecting property to prevent hoisting of V instructions like vmv.v.i by LICM when the VL is a constant. Because of where our VSETVLI insertion step happens in the pipeline, the register allocator is unable to rematerialize the vmv.v.i back to its uses to avoid copies. The VL physical register dependency prevents it. This is bad for register pressure, especially at larger LMUL values. By passing the constant VL to a sideeffecting vsetvli instruction and then passing the result to the vmv.v.i the hoisting is suppressed.