[llvm-branch-commits] [llvm] [AMDGPU] Add machine-level inliner pass (PR #169476)

Diana Picus via llvm-branch-commits llvm-branch-commits at lists.llvm.org
Fri Mar 6 04:12:04 PST 2026


rovka wrote:

> It sounds like this inliner is needed to generate correct code. CC @arsenm

Technically the code is correct without the inliner, we'd just like to inline in order to get rid of the branch and potentially enable some other late optimizations.
 
> Are there any limitations on using this special function? For example, is it only allowed to be called through the intrinsic?

Yes, that's the intention. 

> Can it interact with other functions, especially during IPO?

Kind of? It shouldn't get inlined into other functions (and IIUC the intrinsic should help prevent that), but it's ok for "normal" functions to be inlined into whole wave functions. In general, moving code into whole wave functions should be ok, but moving code out of them is not. To be honest I haven't gone through all our IPO to see if anything might look through the intrinsic and move code out (most analyses should be fine though, since I don't think they care about the WWM-ness of anything).

>Is it allowed to contain LDS definitions?

Probably? I need to think about this a bit more.

> Can it be called from another TU, or is it limited to the current TU? Will the intrinsic function call appear as an edge in the call graph?

At the moment we're assuming they're only called from the current TU, but I am planning to support partial inlining, so then it should be possible to handle them like any other function. The intrinsic call should appear as an edge in the call graph (but it does need the `!callback` metadata for that to work). That's actually pretty important, otherwise we wouldn't be running the pass pipeline on the callees first, so their MIR wouldn't be available when inlining.

> My concern is that this could break any call graph information generated at the IR level, as well as other related analysis built on top of it, which we need in order to properly support external function calls. CC @scchan

That's a very valid concern, I didn't realize we were doing that. I'll have a look.

https://github.com/llvm/llvm-project/pull/169476


More information about the llvm-branch-commits mailing list