Better discipline for interaction between Halide and LLVM types in CodeGen_LLVM.

[zvookin]

This is a tracking bug recording a general thing encountred while adding SVE2 and braoder scalable vector support.

Currently code generation for LLVM IR works by setting the value member of the CodeGen_LLVM derivative to an LLVM::Value * as Halide IR is processed. In this process, Halide relies on being able to recover type information from LLVM values in many places throughout code generation. CodeGen_LLVM also maintains a symbol table mapping names to LLVM values.

So far there have been two cases where LLVM IR has evolved away from having types that match Halide's closely enough to facilitate this recovery. The first was opaque pointers, in which LLVM removed the target type from pointer type specifications. The second is scalable vectors where it is no longer possible to recover the absolute lane width from an LLVM vector type in all cases. Both of these have required significant changes to CodeGen_LLVM and its derived classes, well in excess of those required to match new LLVM APIs.

There are also cases where Halide type system does not fully encode LLVM types and we rely on casting to or matching the LLVM type at codegen time. Generally adapting to the types of formal arguments of functions.

Some amount of this is unavoidable but we should should add documentation and limit the type change casting can accomplish to exactly what is necessary. Where possible, type information should only be obtained from Halide IR rather than being queried from the LLVM IR already generated.

One possible improvement is to carry Halide type information along with LLVM values by making the value member of CodeGen_LLVM a structure that has a Halide::Type and an LLVM::Value *. This would allow recovering exact vector sizes vectors that are either scalable or rounded up in size for code gen purposes. On some architectures, it would be profitable to apply predication masks sized per the Halide::Type to implement arbitrarily sized subvectors. (Yes, LLVM probably could do this internally, but experience suggest that rely on such across architectures is unwise.)

[steven-johnson]

How valuable do think this exercise might be? From casual inspection, it would be a pretty messy change -- everyplace in CodeGen that touches value would need to also examine/update a type as well, with lots of room for error.