similar to: [RFC] Add IR level interprocedural outliner for code size.

Hi Evgeny, I know of the current machine outliner in LLVM. If you look in the "More detailed performance data" in the end section it includes performance comparisons to the machine outliner. As for the algorithmic approach they are kind of similar. Machine Outliner: - Builds a suffix tree based on identical equivalence between machine instrs. - Uses target specific cost model for

Hey Everybody, A little while ago I posted an RFC( http://lists.llvm.org/pipermail/llvm-dev/2017-July/115666.html) with the proposition of adding a new outliner at the IR level. There was some confusion and many questions regarding the proposal which I’d like to address here: Note about nomenclature: Candidate: A repeated sequence of instructions within a module. Occurrence: One instance

Hey Gerolf, On Thu, Sep 21, 2017 at 7:10 PM, Gerolf Hoflehner <ghoflehner at apple.com> wrote: > In general I would love to see an outliner at the IR level also. But > rather than a comparison vs. the machine outliner I would like to learn > more about how the core data structures between the outliners will be > shared. > The only structure that needs to be shared is a

Hi Andrey, Questions and feedback are very much welcome. - The explanation as to why the improvements can vary between the IR and MIR outliner mainly boil down to the level of abstraction that each are working at. The MIR level has very accurate heuristics and is effectively the last post ISel target independent code gen pass. The IR outliner on the other hand has more estimation in the cost

In general I would love to see an outliner at the IR level also. But rather than a comparison vs. the machine outliner I would like to learn more about how the core data structures between the outliners will be shared. In particular for matching/pruning it seems to be a reasonable approach. A few more remarks/questions are below also. Thanks Gerolf > On Sep 5, 2017, at 4:16 PM, River Riddle

> On Sep 21, 2017, at 8:02 PM, River Riddle <riddleriver at gmail.com> wrote: > > Hey Gerolf, > > On Thu, Sep 21, 2017 at 7:10 PM, Gerolf Hoflehner <ghoflehner at apple.com <mailto:ghoflehner at apple.com>> wrote: > In general I would love to see an outliner at the IR level also. But rather than a comparison vs. the machine outliner I would like to learn more

> On Jul 25, 2017, at 9:24 AM, Jessica Paquette <jpaquette at apple.com> wrote: > >> The two passes are pretty different in their approaches to congruency finding, so I don't think it helps to group them as though they were interchangeable "outliner technology". The two passes might be totally orthogonal. > > I think that based off how River described his

Hi Jessica, Thanks for the feedback. I believe the existing partial inliner pass does use some common utilities like the code extractor to do outlining. Is that what you're referring to? I don't recall seeing any other passes that has outlining other than the machine outliner, but I may have missed something. I briefly looked at River's RFC and it seems he's mainly utilizing

Hi Jessica, The comparison to the inliner is an interesting one but we think it's important to note the difference in the use of heuristics. The inliner is juggling many different tasks at the same time, execution speed, code size, etc. which can cause the parameters to be very sensitive depending on the benchmark/platform/etc. The outliners heuristics are focused solely on the potential code

On Tue, Aug 15, 2017 at 4:14 PM, River Riddle via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hey Graham, > I worked on pretty much this exact thing last year. I did something > similar to what you described, I traversed the CFG and built potentially > profitable regions from any given valid start node. At that point there > were several road blocks that prevented it

On Mon, Jul 24, 2017 at 4:14 PM, Quentin Colombet via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi River, > > On Jul 24, 2017, at 2:36 PM, River Riddle <riddleriver at gmail.com> wrote: > > Hi Quentin, > I appreciate the feedback. When I reference the cost of Target Hooks it's > mainly for maintainability and cost on a target author. We want to keep the

Hi Chris, > One particular disagreement that I think very much needs to be revisited in this thread was Jessica's proposal of a pipeline of: > 1. IR outline > 2. Inline > 3. MIR outline IMHO, there is no need to restrict a place of the Outliner in the pipeline at the moment. I hope people representing different architectures will try different configurations and the best will be

Hi River, Thanks for the detailed explanation. If people are okay for you to move forward, like I said to Andrey, I won’t oppose. I feel sad we have to split our effort on outlining technology, but I certainly don’t pretend to know what is best! The bottom line is if people are happy with that going in, the conversation on the details can continue in parallel. > On Jul 24, 2017, at 4:56 PM,

Hi Quentin, I understand your points and I believe that some meaning is being lost via email. For performance it's true that that cost isn't necessarily modeled, there is currently only support for using profile data to avoid mitigate that. I was working under the assumption, possibly incorrectly, that at Oz we favor small code over anything else including runtime performance. This is

Hi Quentin, I appreciate the feedback. When I reference the cost of Target Hooks it's mainly for maintainability and cost on a target author. We want to keep the intrusion into target information minimized. The heuristics used for the outliner are the same used by any other IR level pass seeking target information, i.e TTI for the most part. I can see where you are coming from with

Apologies for delayed joining of this discussion, but I had a few notes from this thread that I really wanted to chime in about. River, I don't mean to put you on the spot, but I do want to start on a semantic issue. In several places in the thread you used the words "we" and "our" to imply that you're not alone in writing this (which is totally fine), but your

I think that, given previous discussion on the topic, we might want a split like this: (1) Search structure Suffix tree or suffix array. (2) Numbering/mapping/congruence scheme Every outliner should implement a function that maps instructions (or whatever structure you want to outline, crazy thoughts…) to integers. That should be passed to the search structure, which will return a list of

Hi Andrew, Thanks for this great work and presentation, I've also a huge interest in code size reduction. I already looked at the first IR Outliner proposal, and I really like your more general approach. I wanted to look at the impact on ARM targets, and managed to apply your patchset up to D87311 (the remaining ones which are related to call instructions and GEP need to be reworked to be

2017-07-28 21:58 GMT-07:00 Chris Bieneman via llvm-dev < llvm-dev at lists.llvm.org>: > Apologies for delayed joining of this discussion, but I had a few notes > from this thread that I really wanted to chime in about. > > River, > > I don't mean to put you on the spot, but I do want to start on a semantic > issue. In several places in the thread you used the words

On Wed, 30 Sep 2020 at 16:48, Andrew Litteken <andrew.litteken at gmail.com> wrote: > > Hi Yvan, > > Glad to hear you’re interested! I’m not sure which ordering you’re looking at the patches, but a cost model was not added to the outliner until D87299. So, if that hasn’t been added I would expect some pretty big code increases since it just outlines whatever similarity it finds