----- Original Message -----> From: "Eric Christopher" <echristo at gmail.com> > To: "Nadav Rotem" <nrotem at apple.com> > Cc: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, October 5, 2012 1:29:50 PM > Subject: Re: [LLVMdev] LLVM Loop Vectorizer > > > Regarding TLI. So, DAGCombine, CodeGenPrepare, LoopReduce all use > > the TLI > > interface which can answer questions such as "is this operation > > supported ?" > > or "is this type legal". This is a subset of what we need in a > > vectorized. > > We can discuss other requirements that the vectorizer may have > > after we > > finish with the first phase. I suspect that we may have to > > refactor some > > functionality out of TLI. > > > > Possibly, though I think TargetData should still be able to get you > what you want.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. 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. -Hal> > > > > Currently TLI is only available in LLC. I suggest that we merge LLC > > and OPT > > into a single tool that will drive both IR-level passes and the > > codegen. > > > > *shrug* I really don't think this is necessary either. There's really > no need for > merging the two tools (and IMO would weaken the separation here). Why > not just have TargetData/TargetLoweringInfo in opt? > > > I agree that it is not necessary for many optimizations. However, > > this is > > absolutely needed for lower-level transformations such as strength > > reduction. So, I plan to keep the current behavior that OPT has > > where if a > > target information is not provided through the command line then > > TargetData > > is kept uninitialized (null pointer). So, as far as IR-level passes > > go, > > nothing is going to change. > > > > TargetData is pretty useful during opt if it's available, probably no > need to merge > the tools though. > > -eric > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
> 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. >You quite obviously misunderstood me.> 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. >Making the data available to the passes is just fine, I don't see a need to merge the two tools. -eric
Hal, Nadav; I think we're piling too many issues into this one thread: On Fri, Oct 5, 2012 at 11:43 AM, Hal Finkel <hfinkel at anl.gov> wrote:> 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. >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. Particularly:> 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. >I think this type of refactoring should *not* be discussed in the same thread. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121005/a7afa163/attachment.html>
----- Original Message -----> From: "Eric Christopher" <echristo at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu>, "Nadav Rotem" <nrotem at apple.com> > Sent: Friday, October 5, 2012 1:49:51 PM > Subject: Re: [LLVMdev] LLVM Loop Vectorizer > > > 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. > > > > You quite obviously misunderstood me.Indeed I did. I apologize.> > > 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. > > > > Making the data available to the passes is just fine, I don't see a > need to merge the two tools.Fair enough. Do you think that we should move LSR into OPT once that is possible? -Hal> > -eric >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
On Oct 5, 2012, at 11:49 AM, Eric Christopher <echristo at gmail.com> wrote:>> 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. >> > > You quite obviously misunderstood me. > >> 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. >> > > Making the data available to the passes is just fine, I don't see a > need to merge the two tools.If the two tools need to link in the same stuff, it just comes down to command line interfaces. I think it makes a lot of sense to make an llvm-cli tool (or whatever) that does something great, then provide opt/llc bourne shell scripts so that my finger memory still works. I get an llvm that doesn't spend forever linking when I build it, *and* muscle memory still works :) -Chris
On Oct 5, 2012, at 11:51 AM, Chandler Carruth <chandlerc at google.com> wrote:> Hal, Nadav; I think we're piling too many issues into this one thread: > > On Fri, Oct 5, 2012 at 11:43 AM, Hal Finkel <hfinkel at anl.gov> wrote: > 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. > > 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.+1> > Particularly: > 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. > > I think this type of refactoring should *not* be discussed in the same thread. > > 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.+1 :) -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121005/36ffb0a6/attachment.html>