
<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 Oct 5, 2012, at 11:51 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hal, Nadav; I think we're piling too many issues into this one thread:</div><div><br></div>On Fri, Oct 5, 2012 at 11:43 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank" class="cremed">hfinkel@anl.gov</a>></span> wrote:<br>

<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">I think this is the wrong way to look at the problem. The real question is: why should we keep OPT and LLC separate? Keeping them separate and using some extension of TargetData will just mean manually duplicating information in this extended TargetData that we otherwise have in the backends. This is error-prone [from personal experience] and otherwise unproductive.<br>

</div></blockquote><div><br></div><div>I think Nadav should start a separate thread on merging the tools. I actually think this makes a lot of sense, for a lot of much more basic reasons than anything to do with what is being discussed on this thread. I suspect there are very basic reasons why this makes a certain amount of sense.</div></div></div></blockquote><div><br></div>+1</div><div><br><blockquote type="cite"><div class="gmail_extra"><div class="gmail_quote">

<div><br></div><div>Particularly:</div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div class="im"></div>

In addition, merging the tools will allow the consolidation of target-specific code in OPT. There is code in InstCombine, for example, that specifically deals with x86 intrinsics. This code should be moved into a callback provided by the x86 target. Currently, however, this is not possible because of this separation.<br>

</blockquote><div><br></div><div>I think this type of refactoring should *not* be discussed in the same thread.</div><div><br></div><div>Changing the factoring of the command line tools which are used by developers for testing and debugging should be discussed separately from changing the fundamental factoring of the LLVM libraries, and the various layering concerns there.</div>

</div></div></blockquote><br></div><div>+1 :)</div><div><br></div><div>-Chris</div><br></body></html>