tbaa_gcframe

[yuyichao]

Add tbaa_gcframe and use it to decorate all stores and loads to/from the GC frame.
This doesn't rely on the the codegen rewrite so it should be easily back ported (probably after 0.4.0).

This is also yet another way to fix the performance issue in #13459 and #13461 .

Close #13301 (Load from gc frame is still bad but it doesn't prevent vectorization anymore)

@vtjnash @simonster .

@carnaval , you also mentioned this during JuliaCon.

[yuyichao]

..... hopefully compatible with LLVM 3.3 this time....

Edit: OK, that failed, so there's basically no way around ifdef's....

[yuyichao]

Finally make it compatible with LLVM 3.3 and all CI passes...

[KristofferC]

Can confirm that for example fill!(A, 0.) and A[:] = 0. has the same performance on this branch.

[vtjnash]

I'm concerned this can manage to walk too far through a gcframe and mark a load of a field of a variable. We don't usually emit code of that form currently, but I don't think such a scenario is too unlikely. For the PR, I think marking the load/store in the emit_var / emit_assignment sections should be sufficient. The temporary variables slot usages will always be closely preceding a function call anyways.

For testing against multiple llvm versions locally, what I do is make configure O=build-llvm37 && cd build-llvm37 && echo 'LLVM_VER = 3.7.0' >> Make.user && make. It'll inherit any settings from your global Make.user file, then override those with the settings in the subfolder.

[yuyichao]

I'm concerned this can manage to walk too far through a gcframe and mark a load of a field of a variable.

Will this matter? If we endup storing random structures (as oppose to just the pointer to them) to the GC frame, those load are still going to be from the GC frame since AFAIK the instructions I'm following getelementptr and bitcast only does pointer algorithms and not load. (i.e. gcframe[offset]->field won't be marked).

[vtjnash]

it matters for alias analysis, since you could have another load/store to the same location that doesn't get marked the same way

[yuyichao]

I rebased this on top of current master. It is still tracing the gep's for some instructions but should be more fine grain than before. Depending on how we add stack allocated object, in the worst case we can add a special gc root allocation intrinsics that is ignored by this marking (if we simply allocate it on the stack with a tag we might not need to do anything special).

With this patch the issue in #15717 still exists (seems that there's too many stores for llvm to naively hoist out of the loop) but SIMD finally works with -O3.

@vtjnash

[yuyichao]

runbenchmarks("simd", vs = "JuliaLang/julia:master")

[nanosoldier]

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