[llvm-dev] [SPIR-V] SPIR-V in LLVM

[Nicholas Wilson via llvm-dev]

>Right, what I was trying to say is that there are more benefits from

>having this not be a target than there is from having it be a target.


Please enumerate them, I have seen none posted so far . The implied “it is what all the the other backends do” w.r.t ISel/MC is at best(worst?) an implementation detail, and I’m still not quite sure why Chandler was so adamant about that. He seemed to imply that generating straight from the IR (as opposed to post legalisation?) introduces a direct dependance in the IR that the rest of LLVM would then be required to not break? I agree that the SPIRV backend should be insulated from changes the IR, although I’m not sure how to achieve that property. I’m also not sure how much, if at all, it would be susceptible to that to begin with. Deletions of instructions/attributes would obviously cause breakage and additions may cause unhandled and/or invalid combinations. I still don’t get the severity if this though, insight appreciated.

>What you are proposing is a lot of work, and even if it does help to
>avoid some duplicate work (which to be honest, I still don't quite
>understand what duplication there would be if it weren't a target),
>I don't think that is enough to justify the effort required.

My point is that (modulo metadata, which I am still  investigating better alternatives, and calling conventions) if SPIRV is a target, then a producer need not change their compilation pipeline at all to target SPIRV. There should be no effort required, it would come as a property of being a target. I think we are confusing each other again :(

Leaving that aside for a moment, there are a number of advantages/requirements that, correct me if I’m wrong, would be impossible without a proper target.

* Most critically: Intrinsics. I am almost certain that you would not accept the current mangling hacks, and if I am to support windows neither can I. Any solution would therefore need to be able to register intrinsics and I believe this is impossible without a target (and even if it is, it makes less sense than a target that doesn’t use ISel/MC). Not being able to use intrinsics is a complete deal breaker.

*Basic optimisations (basic CSE,DCE,inlining): requires a TargetLibraryInfoImpl(?) which I believe requires a target. While not strictly necessary it would improve the readability of the resulting IR/SPIRV. All of the more complex optimisations would be done “post ingestion” of the SPIRV and with a different target triple so are unaffected by any decision made. See my reply to Hongbin for an approach.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170503/d26ad405/attachment.html>