Add !noalias and !alias.scope metadata

[topolarity]

The motivation here is that the TBAA domain is ill-equipped for reasoning about regions. In particular, it suffers total precision loss when merging disparate types in a memcpy causing #47138.

As suggested by @vtjnash, !noalias should probably be used for region-based memory information and !tbaa should be used exclusively for layout. This change adds !noalias annotations without modifying the TBAA hierarchy.

All of the "interesting" changes are in 7313b7f (which resolves #47138 on its own). b08c644 just rolls out the same trick over (nearly) all other loads/stores.

We'll want to follow up soon to prune the TBAA hierarchy, which I think will be a strict improvement.

[gbaraldi]

I gave it a once over and it LGTM, probably deserves nanosoldier/pkgeval runs though.

[gbaraldi]

@nanosoldier runbenchmarks(ALL, vs=":master")

[gbaraldi]

@nanosoldier runtests()

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[N5N3]

I can confirm that the example in #47138 get fixed by this PR.
But looks like the regression still holds for the following simple case

julia> f(a, b) = for i in eachindex(a, b)
       a[i] = b[i]
       end
f (generic function with 2 methods)

julia> code_llvm(f, Tuple{Vector{ComplexF64},Vector{ComplexF64}})

[gbaraldi]

At least locally, I get 66ns on master, 33ns on this PR and 23ns on 1.8. So it seems we've gotten a bit better here, but there's still something left.

That something being lowering that memmove doesn't use SIMD.

[N5N3]

IIRC (The build has been deleted), the memmove happens in a loop block.
And 1.8 also generates memmove for non-simd cases, e.g.
code_llvm(f, Tuple{Vector{Tuple{Int,Int32}},Vector{Tuple{Int,Int32}}})

[gbaraldi]

It generates a memmove because it can't prove the two arrays passed to the function don't alias each other.
The new framework as is assumes that all mutable julia objects may alias eachother if I understood it correctly.

[N5N3]

But I thought LLVM's vectorlizer is able to add a memcheck block and try to use simd if valid?

[gbaraldi]

I'm not sure if llvm is taking the noaliasthing and using it as the full truth, or if the vectorizer isn't running here because you don't get separate loads and stores.

[N5N3]

I just check the Clang result. It vectorlized well. (Well, the input for LV pass does have seperate load and store...)
Perhaps we need some pass tuning?

[gbaraldi]

So memcpyopt is transforming our memcpys into a memmove. Also your clang example isn't the same as your julia one.
If you make a similar struct in julia, with this PR. You get the vectorization as expected. If you make it so the struct is bigger you get memcpys in the loop.

[N5N3]

Also your clang example isn't the same as your julia one.

Oh my fault, didn't notice that. So at least ComplexF32 would be as fast as 1.8 after this PR.

[nanosoldier]

Your package evaluation job has completed - possible new issues were detected.
A full report can be found here.

[vtjnash]

@nanosoldier runbenchmarks("blas", vs=":master")

[nanosoldier]

Your benchmark job has completed - no performance regressions were detected. A full report can be found here.