These are chat archives for libmir/public

21st
Jul 2017
Jakob Bornecrantz
@Wallbraker
Jul 21 2017 11:59
@thewilsonator Okay thanks, I was more thinking about what's needed to upstream the SPRIV backend(s?). And if there is anything I can help with doing that.
Nicholas Wilson
@thewilsonator
Jul 21 2017 13:01
@Wallbraker I think its mostly "political", see this for the full thread. There is now three backends, mine, KhronosGroup's and Codeplay's and I'm trying to convince everyone to collaborate. If you're interested, the TableGen backend is the next thing that needs doing, but I'm going to wait and see if I can convince someone else to do it for me ;) (either you or authors of the other SPIR-V backends). It it alas rather boring work, although thrilling in comparison to writing the tablegen desctriptions.
Jakob Bornecrantz
@Wallbraker
Jul 21 2017 13:15
@thewilsonator So they have basically said no no-tabelgen backend will go in?
Or was that just some loud people who have no influence?
Nicholas Wilson
@thewilsonator
Jul 21 2017 13:25
That zealotry, if its the one I assume you're talking about, was about not accepting a non MI/legalised backend because that would force them to not break IR compatibly with the rest of the backends(?), I dont really under stand that either. However they did relent and decided that IR -> SPIR-V is the only viable approach.
_I_ want a tabelgen backend so that intrinsics work and so I can get Windows to work without having to use pragma(mangle, "...") on all the OpenCL declarations.
Jakob Bornecrantz
@Wallbraker
Jul 21 2017 13:26
Okay, I don't know that much about LLVM internals as I am a frontend writer.
Just wondering if I should have written a angry letter telling them to get thier shit together
Nicholas Wilson
@thewilsonator
Jul 21 2017 13:28
A few of those emails were rather circular, lol.
It's probably best to focus effort on dcompute as the ROI is much higher.
While it is annoying to maintain my own backend it is doable.
When I go to IWOCL next may I'll push as hard as I can to get this sorted out once and for all.
Jakob Bornecrantz
@Wallbraker
Jul 21 2017 13:31
Thanks, I'm working on a different frontend then DCompute. Just sad to see your work go to "waste" sitting in a branch, that I and a lot of other people could use.
Nicholas Wilson
@thewilsonator
Jul 21 2017 13:34
Oh, there are other people using my backend see thewilsonator/llvm-target-spirv#1
but it would be nice not to have to recompile and upload a release every time LLVM trunk breaks LDC compatibility.
not to mention the amount of havoc I must be causing for downstream users of my fork.
Jakob Bornecrantz
@Wallbraker
Jul 21 2017 13:38
Yeah exactly. I'm a C API user so that's not a big deal for me, just I want to be able to point users to the latest LLVM release and tell the to use that.
Nicholas Wilson
@thewilsonator
Jul 21 2017 13:40
I suppose thats not quite so bad, but I imagine it must not be very fun to be trying to juggle clang trunk on top of that.
Jakob Bornecrantz
@Wallbraker
Jul 21 2017 13:47
Even better not using clang, frontend is written in D :)
Nicholas Wilson
@thewilsonator
Jul 21 2017 13:51
Ah I see you have a complier for a different programming language. I saw the D projects in your profile got very confused for a moment ;)
Oh well best of luck on your frontend, and I'll see if I can get the different SPIR-V backends to unite and get included in LLVM.
Jakob Bornecrantz
@Wallbraker
Jul 21 2017 14:46
Thanks! And I hope I can help out in that process in some form :)