<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Apr 18, 2013, at 7:55 AM, <a href="mailto:dag@cray.com">dag@cray.com</a> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Andrew Trick <<a href="mailto:atrick@apple.com">atrick@apple.com</a>> writes:<br><br><blockquote type="cite">David was asking for a post-register-rewrite analysis, which I think<br>is a totally different problem and best implemented separately by each<br>target.  The target knows best which register units are overwritten or<br>preserved by an operation. We try to fake it with<br>undef/implicit-use/implicit-def, but it isn't reliable. Reaching defs<br>just can't be reliably rediscovered in a generic way after we drop<br>explicit subregister information.<br></blockquote><br>I don't see why not.  All of the subregister information is exposed in a<br>generic way through TargetRegisterInfo.<br><br>Your statement that undef/implicit-use/implicit-def isn't reliable is<br></div></blockquote><div><br></div><div>It may currently work well for your target. But it's easy for other targets to add a pass that breaks these guarantees but still generates correct code. </div><div><br></div><div>The last example I remember from the mailing list was copying an ARM S register using two neon VEXTs.</div><div><br></div><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">news to me.  It seems unsafe to even provide it if it's incorrect.<br></div></blockquote></div><div><br></div>I completely agree which is exactly why I think they should be eliminated and would discourage a generic postRA data flow framework based on them.<br><div><br></div><div>-Andy</div></body></html>