<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Feb 2, 2018, at 1:09 PM, via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" class="">llvm-commits@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Feb 2, 2018, at 12:55 PM, Quentin Colombet <<a href="mailto:qcolombet@apple.com" class="">qcolombet@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Feb 2, 2018, at 12:21 PM, <a href="mailto:escha@apple.com" class="">escha@apple.com</a> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I mean, in that case we are likely to have to mark every single opcode (all 12,000 or so) with this requirement. At that point we might as well just opt out of the pass, I think? At least, it feels like a gross hack that papers over the fact that LLVM has changed how register classes work such that our entire approach is no longer valid.<div class=""><br class=""></div><div class="">Also, it seems very weird to make this constraint-violating behavior *opt-out*. Maybe it should be opt-in, i.e. put doesNotHaveExtraSrcRegAllocReq on all instructions it’s okay for?</div></div></div></blockquote><div class=""><br class=""></div><div class="">That sounds like a better approach to me.</div><div class="">After talking with escha, I agree that TableGen is not necessarily expressive enough to model all the constraints that need to be met and I would err on the safe side of being opt-in instead of opt-out.</div></div></div></div></blockquote><br class=""></div><div class="">this is actually worse than i initially realized. one of our targets is VLIW and is completely broken by this patch, *even if we opt out as described*, because it doesn’t iterate over the operands of a bundle. so for example:</div><div class=""><br class=""></div><div class="">r3 = COPY foo</div><div class="">BUNDLE_TYPE_FOO</div><div class=""><thing that uses r3></div><div class="">END</div><div class=""><br class=""></div><div class="">it believes that r3 is dead because it doesn’t iterate over the bundle operands, so it never sees the use of r3.</div></div></div></blockquote><div><br class=""></div><div>As far as I know current llvm code expects you that the "bundle header" (= the first instruction of a bundle) duplicates the operands used inside the bundle as necessary. This is true at last Post-RA[1].</div><div><br class=""></div><div>- Matthias</div><div><br class=""></div><div><br class=""></div><div>[1] Admittedly last time I asked on the list some people claimed bundle headers are not necessary anymore; but from working more with it I am 99% sure that you need bundle headers Post-RA; the RA passes themselfes and the scheduler do indeed work without them.</div></div></body></html>