similar to: [RFC] Framework for Finding and Using Similarity at the IR Level

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

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

Indeed, an awesome project and an excellent report! Code size doesn't really get much attention, so the level of detail and the strong roadmap is refreshing. Hopefully, the project will provide execution times along with code-size > reductions. > I doubt it. Outlining will (almost?) always make for slower code due to a lot more calls being made. But that's ok for embedded targets,

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

On Wed, Sep 27, 2017 at 9:28 AM, Jessica Paquette via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > 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

> On Sep 27, 2017, at 3:23 PM, Davide Italiano via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Wed, Sep 27, 2017 at 9:28 AM, Jessica Paquette via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> I think that, given previous discussion on the topic, we might want a split >> like this: >>

Hi Davide, Thanks! I think that this is a really great thing to be pushing forward in general. > That said, do we really want encapsulate the logic for finding > candidates into an interface? It's unclear whether it should live but > it seems much more akin to the stuff living in Transforms/Utils than a > proper interface. > So, IMHO it's much more suitable for an

On Wed, Sep 27, 2017 at 6:07 PM, Matthias Braun <mbraun at apple.com> wrote: > > On Sep 27, 2017, at 3:23 PM, Davide Italiano via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > On Wed, Sep 27, 2017 at 9:28 AM, Jessica Paquette via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > I think that, given previous discussion on the topic, we might want

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

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

> 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

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

----- Original Message ----- > From: "Daniel Berlin" <dberlin at dberlin.org> > To: "Quentin Colombet" <qcolombet at apple.com> > Cc: "Hal Finkel" <hfinkel at anl.gov>, "llvm-dev" > <llvm-dev at lists.llvm.org> > Sent: Friday, August 26, 2016 11:06:56 PM > Subject: Re: [llvm-dev] [RFC] Interprocedural MIR-level

Daniel, I wonder what the NewGVN would generate for the following C code: int a, b; int foo() { return a + b; } int bar() { return a + b; } ? Obviously, the expressions would be the same ("value1 + value2"), but a single operator is not worthy to be outlined. What classes of congruency would be assigned to operands? The same for both reads of "a" and "b"? If

Hi all, The MachineOutliner has come a long way since the original incarnation presented at the 2016 LLVM Developer's Meeting [1]. In particular, we've been pushing a lot on the AArch64 target for the MachineOutliner. It's mature enough at this point that we'd like to take things a step further and turn it on by default in AArch64 under -Oz. Since the primary goal of -Oz is

Hi, I let Jessica give more details but here are some insights. MIR offers a straight forward way to model benefits, because we know which instructions we remove and which one we add and there are no overhead of setting up parameters. Indeed, since the coloring will be the same between the different outlining candidates, the call is just a jump somewhere else. We do not have to worry about 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

2017-07-26 9:31 GMT-07:00 Quentin Colombet <qcolombet at apple.com>: > > On Jul 25, 2017, at 10:36 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > > > 2017-07-24 16:14 GMT-07:00 Quentin Colombet via llvm-dev < > llvm-dev at lists.llvm.org>: > >> Hi River, >> >> On Jul 24, 2017, at 2:36 PM, River Riddle <riddleriver at

Sorry, I was using a modified compiler, which by coincidence made the bug much easier to reproduce. In some rare cases, the compiler will use x30 as a general-purpose register; in that case, outlining breaks because the "ret" branches to the wrong address.  Testcase (reproduce with "clang -O3 --target=aarch64-pc-linux-gnu -mllvm -enable-machine-outliner"): extern long g1;

I just ran SPEC at -O3 with the outliner enabled for AArch64 and didn’t get any failures on my end. Which flags did you use? I’m curious about what’s going on here... I used -O3 -mllvm -enable-machine-outliner -arch arm64. - Jessica > On Apr 23, 2018, at 1:41 PM, Jessica Paquette <jpaquette at apple.com> wrote: > > Hi Eli, > >> I just tried some tests, and I'm