The TableGen parsing code has a bug: when parsing a defm statement, it tries to do a final resolution even if inside a top-level loop. This doesn't work, however, if things inside the multiclass being resolved need access to the loop-iteration variable. These defm statements need to be delayed until the top-level loop itself is evaluated.
As a quick example, given this:
multiclass D<bit b> { def A; foreach _ = !if(b, [0], []<int>) in def B; } foreach ShouldI = 0-1 in defm MD#ShouldI : D<ShouldI>;
TableGen would provide a parsing error:
foreach-multiclass.td:93:3: error: attempting to loop over '!if(ShouldI, [0], [])', expected a list foreach _ = !if(b, [0], []<int>) in ^
When the defm resolution is delayed, the evaluation works as expected.
Of course, we've got a proper if statement now! I wonder if it's worth checking that this construction works with that as well as with the foreach dodge?
(It should, because if I remember, if expands to that anyway under the hood. But just in case the implementation changes in future, perhaps.)