----- 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
>> > 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? >In my mind (and it sounds like Chandler may disagree) opt is generally for IR level passes and llc handles codegen along with "oh while we're here we've got some machine IR passes as well". I rather like the delineation since it helps keep more things separate unless absolutely necessary. I'm definitely not wedded to the idea of multiple tools as long as the layering that we have persists. -eric
On Oct 5, 2012, at 11:57 AM, Hal Finkel <hfinkel at anl.gov> wrote:>>> 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?Eric's point is important, that IR canonicalization passes need to be distinct from target lowering passes. If OPT and LLC embody that distinction, then LSR is the loop optimization that is currently in the correct place. Partial unrolling and vectorization should be moved to LLC, along with a slew of other "codegen preparation" hacks that are implemented in OPT for convenience. OPT is super convenient because it allows invoking individual passes and IR serialization. Chandler's right that merging tools is not necessary to solve this problem but a good thing to do anyway for conveinence, as long as we maintain the distinction above at the driver level. -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121005/fd21701f/attachment.html>
On Oct 5, 2012, at 12:08 PM, Eric Christopher <echristo at gmail.com> wrote:>>>> 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? >> > > In my mind (and it sounds like Chandler may disagree) opt is generally > for IR level passes and llc handles codegen along with "oh while we're > here we've got some machine IR passes as well". I rather like the > delineation since it helps keep more things separate unless absolutely > necessary. I'm definitely not wedded to the idea of multiple tools as > long as the layering that we have persists. >I think that it would be a good idea to keep OPT and LLC around, as wrappers around the new tool (llvm-cli ??). I do not intend to update 5000 LIT tests.> -eric
On Oct 5, 2012, at 1:13 PM, Andrew Trick <atrick at apple.com> wrote:> > On Oct 5, 2012, at 11:57 AM, Hal Finkel <hfinkel at anl.gov> wrote: > >>>> 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? > > Eric's point is important, that IR canonicalization passes need to be distinct from target lowering passes. If OPT and LLC embody that distinction, then LSR is the loop optimization that is currently in the correct place. Partial unrolling and vectorization should be moved to LLC, along with a slew of other "codegen preparation" hacks that are implemented in OPT for convenience. OPT is super convenient because it allows invoking individual passes and IR serialization.I completely agree.> > Chandler's right that merging tools is not necessary to solve this problem but a good thing to do anyway for conveinence, as long as we maintain the distinction above at the driver level. >+1> -Andy > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121005/14fdc73b/attachment.html>