[RFC] Promoting SPIR-V to an official target

LLVM Project
, , ,
4

I generally support the move. I think the SPIRV target meets our standards for official targets.

There are two SPIRV-specific concerns I want to discuss:

  • SPIRV has a (default-disabled) LLVM_INCLUDE_SPIRV_TOOLS_TESTS option, which builds additional tools for testing from a 3rd-party repository. These are then conditionally used in most tests. Is there any significant risk that developers who don’t enable this option (i.e. anyone not working on SPIRV) will break tests using it?

  • SPIRV is significantly different from other (non-DirectX) targets in that it produces a fairly high level IR whose design is inspired by how LLVM looked like a decade ago. In particular, without the SPV_KHR_untyped_pointers extension, SPIRV uses typed pointers, which caused major complications during the opaque pointers migration. I’d like to understand to what degree we can expect SPIRV to cause problems for future changes to LLVM IR design. For example, would any of the following changes require substantial work for SPIRV support?

    • Migrating getelementptr to ptradd ([RFC] Replacing getelementptr with ptradd). In short, only supporting getelementptr i8, ptr %p, i64 %offset, with the offset calculation being explicit.
    • Only specifying type size in allocas (and byval etc). In short, replacing alloca %T with alloca [sizeof_T x i8].
    • Representing global initializers as bags of bytes with relocations. In short, composing all initializers from sequences of [N x i8] and ptr only.

    If they require substantial work, can SPIRV maintainers commit to making any necessary changes in a reasonable time-frame (days, not years)?

1 Like