Thanks for having a look Hendrik. I'm gonna push this considering there has been no push back for a month. If somebody wants to further comment on this or pitch for a revert please let me know.

Changed comment

ping :)

ping

ping

Inverted condition for error.

ping

Adding an attribute in DAGCombiner that caches disableGenericCombines() calls.

Changing to a disable flag.

LGTM

I don't get completely what is the difference between this and just calling insertMBBInMaps() with the new block created by split as the argument. Shouldn't the insertion point being automatically devised correctly if the block is inserted in the right position?

I'm abandoning this for now based on the fact that I have another patch that ports DeadMachineInstrs to LivePhysRegs. LivePhysRegs though doesn't seem to care about predicates as well ... Probably the fix might need to go there

use addLiveOuts()

Moving to LivePhysReg

LGTM

I wonder if it would make sense to test that the SlotIndex is the same as the one of the bundle header after calling the method.

Thanks for the patch! Some speedup in this area was dearly needed!

Addressing Matt's suggestions

Moving the Spiller.h file from lib/CodeGen to include/llvm/CodeGen allowing it to be visible from external users.

ping2 :)

LGTM

Thanks, nice cleanup!

ping

Ok, in this patch I'm stripping away the "TargetPrefix" off the intrinsics.
I don't know if there are some users that might want to keep that (at which point we might add it as a command line option)
but this avoids the nvvm.intr.nvvm.barrier0 problem, making the output just nvvm.intr.barrier0

Fixing typo that made everything useless :P

Addressing comments

Comments addressed

Fixing additional comments.

Removing space

Thanks River for the review. Addressed your comments.

Testing the change by adapting existing test

Updating a stale comment where the old map used to live

In D69498#1725528, @rjmccall wrote:

It absolutely makes sense for Clang as a GPU-programming frontend to set attributes appropriately when targeting the GPU. I'm objecting to making "convergence" and related "code layout is semantics" properties a universal part of the IR semantics that literally every frontend has to know about in order to get reasonable behavior from LLVM. I know that doing so makes sense to GPU backend developers because you mostly work exclusively on GPU toolchains, but AFAIK there are half a dozen GPU frontends and they're all forks of Clang, whereas there are dozens of LLVM frontends out there that don't care about targeting the GPU and quite possibly never will. (And even if they do target GPUs, they often will not care about exposing thread groups; many programming environments are just interested in taking advantage of the GPU's parallel-computation power and have no interest in inter-thread interference.)

John.

Thanks for the answers! It was about time somebody tackled this problem in LLVM :)

What is the expectiation of lowering of a loop like the one you mentioned above?

One thing to probably note is that its not only a "target specific" issue, but a language specific issue as well (IMHO). OpenCL, CUDA, SYCL are all languages (to name a few) that have a concept of "convergence" and its not related only to the fact that they mostly run on a GPU, but to their programming model as well with respect to accessing textures and SIMD-wide communication and decision making (ballot)

In D69078#1712137, @arsenm wrote:

I was just about to do the same