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>
----- Original Message -----> From: "Nadav Rotem" <nrotem at apple.com> > To: "Andrew Trick" <atrick at apple.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "llvmdev at cs.uiuc.edu Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, October 5, 2012 3:20:04 PM > Subject: Re: [LLVMdev] LLVM Loop Vectorizer > > > > > 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.I don't really understand where you want to draw the line. Should the inliner get target-specific input? InstCombine? How about Polly? I think that the answer to all of these questions is probably, at some level, yes. -Hal> > > > > > > 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 > >-- Hal Finkel Postdoctoral Appointee Leadership Computing Facility Argonne National Laboratory
On Oct 5, 2012, at 1:47 PM, Hal Finkel <hfinkel at anl.gov> wrote:> I don't really understand where you want to draw the line. Should the inliner get target-specific input? InstCombine? How about Polly? I think that the answer to all of these questions is probably, at some level, yes.I agree with Eric and Andy that we need to keep the current abstraction of IR-level passes that canonicalize code and Codegen-level passes that optimize the code (with a few exceptions, such as LSR, vectorizer, partial unroll, etc.) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121005/cf1e102f/attachment.html>
On Oct 5, 2012, at 1:47 PM, Hal Finkel <hfinkel at anl.gov> wrote:> I don't really understand where you want to draw the line. Should the inliner get target-specific input?Inlining always does a canonical transformation. It can take whatever target data is available at it's level for heuristics, but that doesn't make it a target lowering pass. Similarly, full unrolling is a canonical transformation that may use target-specific heuristics. Contrast that with partial unrolling or vectorization, which are anti-canonical transformations.> InstCombine?I think there is too much temptation currently to use the canonical InstCombine pass to facilitate instruction selection. It should only facilitate downstream IR analysis and simplification. I see no problem conceptually running an anti-canonical InstCombine as part of codegen that makes use of target hooks. I think this would make ISEL problems easier to deal with, and will eventually be necessary anyway to clean up after other target lowering passes. Obviously not a perfect solution, but better than doing everything in one CodeGenPrepare pass.> How about Polly? I think that the answer to all of these questions is probably, at some level, yes.There is always the option of splitting a loop optimization problem into an early, canonical run to aid analysis, followed by a late target lowering run to optimize codegen. That's only a problem when the canonicalization can badly pessimize the code in a way that loses information or is hard to recover from. -Andy