This is another approach to the same problem as D158271 and D157976. The basic enhancement being done is to allow constant materialization for cases we previously restricted to .vi forms. To keep that from going crazy, I added a cap on the total expansion cost. This can later be merged into a more general scheme like D157976.
The cap value chosen here (4) is fairly insensitive. I saw some slight regressions - cases where an alternate non-constant pool load lowering is better - going to 5, but after that, any value up to 10 (the highest I tested), doesn't seem to impact practical codegen much.
The overall structural difference from D157976 is using built up sequences (analogous to how we handle integer constant materializations) for both costing and expansion. I think we can generalize the same basic idea to avoid the need for lambdas in D157976.
Not set on this approach. Wrote this to see if it worked out, and to trigger more discussion.