Note this assumes the future use of immediate for immarg, not the current situation which G_CONSTANT
I think this is more of a defect in SelectionDAG because handling this correctly is hard. I’m considering adding a pseudo UniformVGPR register bank for cases where readfirstlane is OK
The fact that a readfirstlane is generated instead of a waterfall loop is not a defect in SelectionDAG, at least not in general.
Frontend languages have builtins whose behavior is undefined when certain arguments are dynamically non-uniform. That is, programmers can use them in a context where the compiler cannot possibly prove that the value will be uniform, but the programmer implicitly guarantees that it will be at runtime. Emitting a readfirstlane for those when necessary is the correct behavior.
Such transforms usually aren't optimizations, so mostly they shouldn't be done in the first place...
Okay, so admittedly there may be some cases where going the waterfall route is actually preferable. If this is really the case, then we probably need to do some more thinking about how to properly represent it, perhaps by having the base intrinsics (interp, load/store with resource descriptors) support divergence via waterfall loops, but adding some kind of "assume uniform" intrinsic whose semantics are that it passes through a value similarly to readfirstlane, except that the behavior is actually undefined if the input value is divergent.
Something like that seems like a reasonable long-term direction, but I'd say that goes beyond the scope of this change :)