Exploit SPIRV target transform information for SPIR triple.

[bader]

I found it odd that we need to add a 'Targets' folder in Basic when no other Target seems to require this.

Other targets have this value pulled from the backend via the TargetTransformInfo (which is what I suggested to use), for instance the definition for AMDGCN.

but today we target spir triple, which has no TTI. Once SPIR-V backend is matured enough to support SYCL, we can remove the duplication and use

I'm not suggesting to use the SPIR-V backend as a mean to produce the SPIR-V IR. And the driver won't do that anyway. It is just a case to build the SPIR-V backend so we can make use of target info, features etc.

SPIR could be added as one of the SPIR-V target (from dpc++, this is just a triple really). I know upstream has reservations, but as there is no other target that uses this triple, I don't really see the harm as SPIR is supposed to be used in conjunction with -emit-llvm (again, I'm not suggesting to use the backend to produce anything, just pull data and control generic transformations). We can also emit a warning / error if someone tries to emit SPIR-V using the backend with the SPIR triple if we are worried ppl start to use it as a "normal path".

I have other use cases where this would be extremely useful to do this but I'll stop here as I'm diverging way too much, probably best for an offline discussion.

Originally posted by @Naghasan in #7418 (comment)

[bader]

SPIR could be added as one of the SPIR-V target (from dpc++, this is just a triple really). I know upstream has reservations, but as there is no other target that uses this triple, I don't really see the harm as SPIR is supposed to be used in conjunction with -emit-llvm (again, I'm not suggesting to use the backend to produce anything, just pull data and control generic transformations).

@Naghasan, do you have any pointers to implementations of this approach? I don't think I've seen anything like this in the upstream.

[Naghasan]

Disclaimer: I haven't really work in an LLVM backend in a long time, so take that as a starting point. I still know my way around as I do hacks in the NVPTX and AMDGPU backends in the context of this project.

---

So what I had in mind was basically adding the following entry to LLVMInitializeSPIRVTargetInfo

  RegisterTarget<Triple::spir32> S32(getTheSPIRV32Target(), "spir32",
                                    "SPIR-V 32-bit", "SPIRV");
  RegisterTarget<Triple::spir64> S64(getTheSPIRV64Target(), "spir64",
                                    "SPIR-V 64-bit", "SPIRV");

So now, clang-llvm should be able to automatically bind SPIR triple to the SPIR-V backend. So normally, passes now have access to the target transform info. If need be, that will also enable you to tweak optimization following SPIR-V extension (if you pass them as feature) and start to align with the backend.

Side note about supported SYCL SPIR targets: IIRC, targets like spir64_x86_64 is actually spir64 target and x84_64 subtarget which are under different enums, so the above should capture them as well. Again, TTI could be tweak according to the subtarget if needed.

Important bit before going further, having a backend allows you get some control over passes you want to run. The SPIR-V target already apply some control, and it is defined here. This would probably need to tweaking to not run these passes (although, I forgot when they actually get added to the pipeline).

So with just that, users would also be able to generate SPIR-V using the backend with the SPIR triple by playing with clang invocations but the SYCL clang driver won't allow that path (it uses -emit-llvm-bc then llvm-link etc then llvm-spirv), so a normal user won't trigger that. If you want to warn/ban users from using the backend itself with the SPIR triple, this can be done here

[Naghasan]

@bader issues seen in #8874 (comment) could actually be solved elegantly by exploiting a TTI. As address space inference pass is now ran for SPIR-V target, if we have intrinsics for SPIR-V used, the pass could exploit this to actually see that some of cast are unnecessary and generally help optimizations.