search

GPUOpen-Drivers / llvm-dialects

LLVM Dialects Library
Apache License 2.0
22 stars 22 forks source link

Tags or branches for released LLVM versions #68

Open vchuravy opened 12 months ago

vchuravy commented 12 months ago

I have been eyeing llvm-dialects from afar. I would like to use it to "formailize" Julia's LLVM dialect which is a set of pseudo-intrinsics and usage of custom address-spaces.

Julia doesn't target LLVM ToT, but rather takes the latest stable LLVM release and uses that as a basis for a Julia release. Currently 1.9 is released and 1.10 is in beta.

1.6 -> LLVM 11 1.7 -> LLVM 12 1.8 -> LLVM 13 1.9 -> LLVM 14 1.10 -> LLVM 15 1.11 -> ??? (Probably LLVM 16; maybe LLVM 17 if that's easy)

We pick an LLVM release towards the end/middle of our own development phase and then have a release stabilization process.

So I was trying to figure out the other day which commit I would need to use to try out llvm-dialects on LLVM 15.

I don't expect a change in the development practices here, but it would be nice to document which commit roughly corresponds to which LLVM release (even better to tag a commit that is known to work with a LLVM release)

nhaehnle commented 12 months ago

Hi! I remember we talked about this at some point in the past -- thanks for the interest!

I can't immediately answer the question of which commit maps to which LLVM version. LLPC uses a custom branch that is very close to LLVM top-of-tree, so just correlating commit dates should give a good indication. We do have an internal user that's still a bit behind but trying to catch up (the main blocker is that it hasn't fully moved to opaque pointers), so using a slightly older LLVM may not be too bad..

In fact, as long as Julia is targeting a specific LLVM release and not some random commit, it might actually be best to explicitly support that LLVM release on top of tree llvm-dialects. I'm not saying that we can definitely do this, but we should at least consider it.

So, if you find that some relatively minor changes using guards along the lines of #if LLVM_MAJOR_VERSION <= 16 ... #else ... #endif are sufficient to make it work, I'd be inclined to just take them. The rule for such guards would be that certain released LLVM versions are supported as is, and if LLVM_MAJOR_VERSION indicates "LLVM-next", then the code is expected to work with a fairly recent LLVM top-of-tree (but without any guarantees as to specific branches etc.). I've had good experiences with such a policy in Mesa (for radeonsi).

We could even consider testing against supported LLVM releases in CI, but that's an area I'm not too familiar with so probably needs a bit more thought.

One big question here is: What is Julia's opaque pointer story?

vchuravy commented 12 months ago

One big question here is: What is Julia's opaque pointer story?

We are getting there. We support them fully on our current development branch, but we haven't turned them one in a release build. We are seeing some performance regression and we have a few parts of the GPU ecosystem who are further behind

Right now we are looking into making to customizable for the next release using per context settings xD

nhaehnle commented 12 months ago

Sounds good! Like I said, I think we should consider just supporting specific LLVM releases on top-of-tree (though at some point we'll want to retire non-opaque pointers), so let us know what you find in that regard.