similar to: [LLVMdev] IR Passes and TargetTransformInfo: Straw Man

On 7/16/2013 11:38 PM, Andrew Trick wrote: > Since introducing the new TargetTransformInfo analysis, there has been some confusion over the role of target heuristics in IR passes. A few patches have led to interesting discussions. > > To centralize the discussion, until we get some documentation and better APIs in place, let me throw out an oversimplified Straw Man for a new pass pipline.

On Jul 29, 2013, at 9:05 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 7/16/2013 11:38 PM, Andrew Trick wrote: >> Since introducing the new TargetTransformInfo analysis, there has been some confusion over the role of target heuristics in IR passes. A few patches have led to interesting discussions. >> >> To centralize the discussion, until we get

On 7/29/2013 6:28 PM, Andrew Trick wrote: > > You mean that LICM and Unswitching should be left for later? For the purpose of exposing scalar optimizations, I'm not sure I agree with that but I'd be interested in examples. Optimizations like LICM, and unswitching can potentially damage perfect nesting of loops. For example, consider this nest: for (i) { for (j) {

On Jul 27, 2013, at 5:47 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Hi, Sean: > > I'm sorry I lie. I didn't mean to lie. I did try to avoid making a *BIG* change > to the IPO pass-ordering for now. However, when I make a minor change to > populateLTOPassManager() by separating module-pass and non-module-passes, I > saw quite a few performance

----- Original Message ----- > > On Jul 27, 2013, at 5:47 PM, Shuxin Yang <shuxin.llvm at gmail.com> > wrote: > > > Hi, Sean: > > > > I'm sorry I lie. I didn't mean to lie. I did try to avoid making > > a *BIG* change > > to the IPO pass-ordering for now. However, when I make a minor > > change to > >

On 7/30/2013 11:44 PM, Chris Lattner wrote: > > The canonical form should be that loop invariants are hoisted. The canonical form should not depend on the knowledge as to what is invariant and what isn't. It has more to do with preserving certain "common" properties of a loop, such as header, preheader, latch branch, etc. > Optimizations should not depend on perfect

On 7/30/13 7:35 AM, Krzysztof Parzyszek wrote: > On 7/29/2013 6:28 PM, Andrew Trick wrote: >> >> You mean that LICM and Unswitching should be left for later? For the >> purpose of exposing scalar optimizations, I'm not sure I agree with >> that but I'd be interested in examples. > > Optimizations like LICM, and unswitching can potentially damage >

On Jul 31, 2013, at 6:53 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 7/30/2013 11:44 PM, Chris Lattner wrote: >> >> The canonical form should be that loop invariants are hoisted. > > The canonical form should not depend on the knowledge as to what is invariant and what isn't. It has more to do with preserving certain "common"

I personally strong abhor this kind of thing:-) I guess I should be more open-minded. For pre-ipo phase, some passes should not invoke, say, any loop nest-opt, loop version, aggressive loop unrolling, vectorization, aggressive inling. The reasons are they will hinder the downstream optimizers if they kick in early. > Out of curiosity, has anyone tried to optimize the pass ordering in some

There seems to be a lot of interest recently in LTO. How do you see the situation of splitting the IR passes between per-TU processing and multi-TU ("link time") processing? -- Sean Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130717/f5310a6e/attachment.html>

Andy and I briefly discussed this the other day, we have not yet got chance to list a detailed pass order for the pre- and post- IPO scalar optimizations. This is wish-list in our mind: pre-IPO: based on the ordering he propose, get rid of the inlining (or just inline tiny func), get rid of all loop xforms... post-IPO: get rid of inlining, or maybe we still need it, only

On 7/31/13 4:30 PM, Tobias Grosser wrote: > On 07/30/2013 09:44 PM, Chris Lattner wrote: >> >> On Jul 30, 2013, at 10:19 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: >> >>> The pro for running LICM early is that it may move big redundant >>> stuff out of loop nest. You never know >>> how big it is. In case you are lucky , you can move

On Jul 30, 2013, at 10:19 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > The pro for running LICM early is that it may move big redundant stuff out of loop nest. You never know > how big it is. In case you are lucky , you can move lot of stuff out of > loop, the loop may become much smaller and hence enable lots of downstream optimizations. This sound > to be a big win

On 07/30/2013 09:44 PM, Chris Lattner wrote: > > On Jul 30, 2013, at 10:19 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > >> The pro for running LICM early is that it may move big redundant stuff out of loop nest. You never know >> how big it is. In case you are lucky , you can move lot of stuff out of >> loop, the loop may become much smaller and hence

On 7/31/2013 12:20 PM, Chris Lattner wrote: > On Jul 31, 2013, at 6:53 AM, Krzysztof Parzyszek > <kparzysz at codeaurora.org <mailto:kparzysz at codeaurora.org>> wrote: >> On 7/30/2013 11:44 PM, Chris Lattner wrote: >>> >>> The canonical form should be that loop invariants are hoisted. >> >> The canonical form should not depend on the knowledge

On 7/31/13 4:47 PM, Shuxin Yang wrote: > > On 7/31/13 4:30 PM, Tobias Grosser wrote: >> On 07/30/2013 09:44 PM, Chris Lattner wrote: >>> >>> On Jul 30, 2013, at 10:19 AM, Shuxin Yang <shuxin.llvm at gmail.com> >>> wrote: >>> >>>> The pro for running LICM early is that it may move big redundant >>>> stuff out of loop

>> I'm talking about perfect loop nests, as in the classical fortran loop >> transformation sense. > > Most nest optimizations only apply to perfect nests. Each such > optimization could try to "fix" the nest for its own purposes, but it > would be a lot of duplicated effort. If each L.N.O pass have to fix by itself, I would say this LNO component is

Hi, Sean: I'm sorry I lie. I didn't mean to lie. I did try to avoid making a *BIG* change to the IPO pass-ordering for now. However, when I make a minor change to populateLTOPassManager() by separating module-pass and non-module-passes, I saw quite a few performance difference, most of them are degradations. Attacking these degradations one by one in a piecemeal manner is wasting

I've added a straw-man of some extra optimization passes that help specific benchmarks here or there by either preparing code better on the way into the vectorizer or cleaning up afterward. These are off by default until there is some consensus on the right path forward, but this way we can all test out the same set of flags, and collaborate on any tweaks to them. The primary principle here

Does LLVM have loop multiversioning ? it seems it does not with clang++ -O3 -mllvm -debug-pass=Arguments program.c -c bash-4.1$ clang++ -O3 -mllvm -debug-pass=Arguments fast_algorithms.c -c clang-3.6: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated Pass Arguments: -datalayout -notti -basictti -x86tti -targetlibinfo -no-aa -tbaa -scoped-noalias