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

So, I changed the getConstantVRegValWithLookThrough function with an extra operand. Honestly I couldn't see any reason why the new parameter should have been set as "false" by default, so I set it to true, because it seems what the design of GlobalISel seems to suggest considering the difference of float/int being "not-there".

Clang-formatted test and corrected "MRI" to "*MRI"

Closed by r359282 (forgot to add differential revision to commit message)

Cleanup

Update coverage

Hi Nikita, thanks for the review. I updated the patch based on your comment.

Here the one with your isWrappedSet changes

Sorry, you are right, I didn't notice the operands were flipped. I'm not familiar with Z3 syntax and I got confused :)

Thanks Nuno,

Ping?

Thanks Alina!

Yeah sure, thanks for suggesting the right person Chandler!

Thanks Matt, committed r340200

Thanks David. I'll address your comment in my commit

ping

Pushed as r322248

LGTM

Hi Andrew, your change modifies the semantics of the function, in the sense that it becomes specialized into just collecting the data to perform "ConvertTwoCaseSwitch()" and it will not be possible to use it for other potential optimization that require the same data.

Thanks Anna.
Addressed your nitpicks.

Updated confusing comment after Anna's suggestion.

Thanks Anna for the review.