[SBF] backport sbpfv3 changes to 1.75.0

[nagisa]

This is unlike the other backports in #156 and #158 in that this particular backport does not preserve the sbf-solana-solana target. This target, however, is dead either way and so keeping it working brings no benefit.

[nagisa]

(I decided to start from the oldest end here because I think its going to be easier to bring the same set of changes forward once the full set of them is determined, rather than going backwards and needing to pull increasingly more and more stuff as the code gets less and less… developed :))

[LucasSte]

This is the case I was fearing.

I believe it is easier to make SBF the new v3 here. The new triple requires quite a few changes on the LLVM side.

[nagisa]

I don't care much either way, but rustc can specify whatever LLVM target it wishes to LLVM. Though I guess the problem with the making sbf be v3 here is more that we wouldn't have the original sbf behaviour available on the llvm side anymore?

Whatever we do on the llvm side, I would still suggest that we expose the target as sbpfv3 on the rust side and, if needed, delete the old sbf rust target.

[LucasSte]

I don't care much either way, but rustc can specify whatever LLVM target it wishes to LLVM.

I remember trying routing different triples to the same target in LLVM in the past, but it didn't work well. I guess because we also need clang support. I had to create all triples in Triple.cpp.

Though I guess the problem with the making sbf be v3 here is more that we wouldn't have the original sbf behaviour available on the llvm side anymore?

We will disable v0 either way, so I don't think we need to maintain the old behavior.

Whatever we do on the llvm side, I would still suggest that we expose the target as sbpfv3 on the rust side and, if needed, delete the old sbf rust target.

Whatever option you choose, make sure to update the behavior of cargo-build-sbf. It invokes the sbf triple for old versions of platform tools.

[LucasSte]

Ah, I can try to just cherry-pick the commit: anza-xyz/llvm-project@08aedd6

[nagisa]

We will disable v0 either way, so I don't think we need to maintain the old behavior.

Alright, I'll adjust accordingly.