Migrate codegen to operate on orc::ThreadSafeModule

[pchintalapudi]

orc::ThreadSafeModule and orc::ThreadSafeContext use reference-counted contexts to allow multiple contexts to be created and destroyed safely during codegen. Moving TSModule to be our API boundary gets us closer to parallelizing codegen without leaking contexts.

Depends on #43770 to remove the global debug information with associated global context #44454 to refactor a few globals.

[pchintalapudi]

There's a few indentation TODOs left in this PR, which I've deliberately left out for now as they cause large whitespace diffs that confuse the diff viewer.

[pchintalapudi]

Per an offline discussion with Valentin, we will change the interface of jl_create_native to accept a TSModule to codegen into rather than creating its own TSModule with a provided TSContext. This allows users of jl_create_native to specify their own data layout and targets for the destination module.

[vchuravy]

Victory

[aviatesk]

@gbaraldi bisected that this commit introduced the error reported at #45302.

[pchintalapudi]

That's interesting, I wouldn't be surprised that there's a hidden bug given the size of the changeset but the changes to jl_merge_module aren't actually meaningful.

[pchintalapudi]

Looks like at least the error in jl_merge_module during LoopVectorization tests is:

Attempting to replace ; Function Attrs: alwaysinline
declare linkonce_odr i32 @"julia_readraw_turbo!_14765u14814"(i32, i32) #4

with global function  ; Function Attrs: alwaysinline
define linkonce_odr i32 @"julia_readraw_turbo!_14765u14814"(i32 %0, i32 %1, i32 %2) #0 {
top:
  %res = call i32 @llvm.x86.bmi.bzhi.32(i32 %0, i32 %1)
  ret i32 %res
}

[pchintalapudi]

And another one:

Attempting to replace ; Function Attrs: alwaysinline
declare linkonce_odr i32 @"julia_rshift_i_avx!_47472u47499"(i32, i32) #3

with global function  ; Function Attrs: alwaysinline
define linkonce_odr i32 @"julia_rshift_i_avx!_47472u47499"(i32 %0, i32 %1, i32 %2) #0 {
top:
  %res = call i32 @llvm.x86.bmi.bzhi.32(i32 %0, i32 %1)
  ret i32 %res
}

Looks like there's a common x86.bmi.bzhi intrinsic that's causing some issues between function definition/declaration

[pchintalapudi]

Reduced to

using LoopVectorization
img1 = Matrix{UInt8}(undef, 10, 10)
raw = rand(UInt8, (30 * 10) ÷ 4)
function readraw_turbo!(img, raw)
         npack = length(raw) ÷ 3
         @turbo for i = 0:npack-1
           img[1+4i] = raw[2+3i] << 4
           img[2+4i] = raw[1+3i]
           img[3+4i] = raw[2+3i]
           img[4+4i] = raw[3+3i]
         end
         img
       end
readraw_turbo!(img1,raw)

[pchintalapudi]

And again to

using LoopVectorization;img1 = Matrix{UInt8}(undef, 10, 10);raw = rand(UInt8, (30 * 10) ÷ 4);function readraw_turbo!(img, raw)
         npack = length(raw) ÷ 3
         @turbo for i = 0:npack-1
           img[1+4i] = raw[2+3i] << 4
         end
         img
       end;readraw_turbo!(img1,raw)

[pchintalapudi]

I am now slightly suspicious of this line: https://github.com/JuliaSIMD/VectorizationBase.jl/blob/9ae47c5c12c7bec9b57c132c24f67c4f14090c9e/src/llvm_intrin/masks.jl#L336

llvmcall_expr(decl, instrs, T, :(Tuple{$T,$T}), typ, [typ, typ, typ], [:a, :b])

I'm not sure, but I'm guessing that the list should only have 2 typ, not 3