[llvm] Allow Specifying SGMasks for Inline Asm (PR #155491)

Patrick Simmons via llvm-commits llvm-commits at lists.llvm.org
Sun Sep 7 01:58:58 PDT 2025


linuxrocks123 wrote:

> > Instead of this, we could add `__builtin_sched_group_barrier_override_sgmask()` with the semantics that a nonzero argument will override the sgmask for any instructions found prior to it. A call with 0 could clear the custom mask. That way, we're both giving users more control and not directly adding any code to support inline assembly.
> 
> All of these built-ins are a hack, and that's adding a hack on top of the hack. All of this stuff is a development resource sink we have to maintain forever and it's not worth it.
> 
> Did you try just interpreting inline asm as matching all classes of instructions, or filtering based on whether there are VGPR or SGPR operands?

I haven't tried testing the inline assembly operands.  I would be hesitant to do that because, although you know the architecture better than I do, I can't imagine every assembly instruction that uses a VGPR is a VALU instruction, and "there's wrong behavior" seems worse than "there's no way to express what I want."

The original user request was to have inline asm match only its own new sgmask bit, which is similar in expressiveness to having it match all classes of instructions.  That approach has the advantage of not possibly changing the scheduling behavior of any existing code that uses sched group barriers, which having it match all classes of instructions could do.  Although I feel the current PR provides maximum expressiveness, since the user is the one that suggested just adding a new bit to sgmask for inline assembly, doing that would almost certainly be expressive enough for his needs and would avoid the need to parse the inline assembly string.

An implementation of the user's original request is in this PR's history at https://github.com/llvm/llvm-project/pull/155491/commits/6f450555dc344c53e66fe4cb23667b231c04fec6.  I can revert this PR back to that commit and then add the tests back if we decide to go that route.

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


More information about the llvm-commits mailing list