Stream: cranelift

Topic: flexible vectors

Sam Parker (Oct 25 2021 at 16:13):

Hi,

As I mentioned last week, I've begun looking into flexible vector support. I want to begin by adding a 'pass' to do type legalization, enabling the consumption of flexible IR and outputting the equivalent using simd128 so that the current backends can consume it without modification. And now that I've finally spent a day looking at the code, I have quite a few questions!

• Would peepmatic support changing the types of the operations, and so handling the whole conversion process?
• Should this be performed in the existing legalize phase?
• Is there somewhere else that we currently do any type legalization?
• What mechanism should be used for the communication of what the backend wants and supports?
• Has anyone got, more concrete, ideas of how to go about any of this? :)

Thanks in advance.

fitzgen (he/him) (Oct 25 2021 at 16:17):

Would peepmatic support changing the types of the operations, and so handling the whole conversion process?

Assuming that we accept the ISLE RFC, I will file a PR to remove peepmatic. ISLE can do the things that peepmatic could do better (once we have lowering in ISLE implemented, I'd like to start porting preopt over to ISLE).

fitzgen (he/him) (Oct 25 2021 at 16:20):

To your larger question: I would imagine that this should happen in the existing legalization pass, and that the target arch would communicate its desires via new method(s) on TargetIsa/MachInst. I'm not familiar enough with the details here to say more than that.

Maybe @Chris Fallin has more ideas.

Chris Fallin (Oct 25 2021 at 16:22):

Greetings @Sam Parker -- I'll pretty much echo what @fitzgen (he/him) says in that I think this depends on ISLE; with a DSL based on rewriting rules, one could imagine a layer of legalization that happens before the machine-specific part, in a way that machines without support for e.g. flexible vectors (or some other feature) get a default simple implementation while machines that have such support can do direct lowering.

Chris Fallin (Oct 25 2021 at 16:23):

There is indeed an existing legalization phase but it's fixed / machine-independent, translating ops like heap_addr to their implementations; I'd prefer in the long run to merge this into a unified legalization strategy based on the DSL (again, all under the condition that we merge ISLE)

Chris Fallin (Oct 25 2021 at 16:24):

Probably this will need a little more design discussion, and maybe another RFC; so it's not quite short-term-ready. I recognize that this probably creates some difficulties for you if you're hoping to implement something soon-ish! I think the best way to prototype would probably be to look at defining what the CLIF ops for flexible vectors will be (this will be fully reusable work); and then doing a direct lowering in aarch64 for now, leaving the x64 and s390x parts with unimplemented!() stubs. Then we can fill in that last corner later as we get a clearer picture of what legalization should look like.

Chris Fallin (Oct 25 2021 at 16:25):

Does that seem reasonable? Happy to discuss more here or in the next biweekly :-)

Sam Parker (Oct 26 2021 at 08:27):

Thank you both. I'm looking forward to the possibilities that ISLE could provide :) and I certainly would have preferred to attempt this once it was available.

So yes, it sounds like going to the direct route to the aarch64 backend is currently the best option. Hopefully I'll make some progress with it this week and have something to discuss at the bi-weekly.

cheers!

fitzgen (he/him) (Oct 26 2021 at 16:21):

Want to add an item to https://github.com/bytecodealliance/wasmtime/blob/main/meetings/cranelift/2021/cranelift-11-01.md ?

Sam Parker (Nov 01 2021 at 14:52):

Argh, sorry, I've only just seen this. I started doing it on Friday and then completely forgot.

Petr Penzin (Nov 18 2021 at 00:12):

I'd be happy to help with this, I am the champion of flexible vectors proposal.

Sam Parker (Nov 18 2021 at 13:43):

Hi @Petr Penzin I'm hoping I can get a very rough RFC up before the holidays, once I've shown I can handle some basics for SVE. My initial thoughts implementing the types is that it makes sense to have 128-bit as the minimum width, and the other sizes are multiples of, so it is (I think) trivial to map onto existing simd-128 implementations.

Amanieu (Nov 18 2021 at 14:49):

Note that on RISC-V the minimum vector width is 64-bit.

Petr Penzin (Nov 18 2021 at 19:59):

Sam Parker said:

My initial thoughts implementing the types is that it makes sense to have 128-bit as the minimum width, and the other sizes are multiples of, so it is (I think) trivial to map onto existing simd-128 implementations.

That is actually the intent, if it isn't stated clearly in the spec it probably should :)

Sam Parker (Dec 17 2021 at 14:00):

I've posted an RFC for sizeless types in cranelift: https://github.com/bytecodealliance/rfcs/pull/19

Last updated: Nov 22 2024 at 16:03 UTC