similar to: Chrome extension for tracking LLVM code review

I'd be interested in using this but I have to wait until someone ports this to firefox (or at least chromium). Thanks for sharing it though! On 3/31/20 2:16 PM, River Riddle via llvm-dev wrote: > For those interested I've uploaded to the chrome store to make installs > easier. An install link is now included on the repo. > > -- River > > On Mon, Mar 30, 2020, 1:44 PM

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

> 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 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 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,

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 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 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 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

> 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

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 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

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

I’m River and I’m a compiler engineer at PlayStation. Recently, I’ve been working on an interprocedural outlining (code folding) pass for code size improvement at the IR level. We hit a couple of use cases that the current code size solutions didn’t handle well enough. Outlining is one of the avenues that seemed potentially beneficial. -- Algorithmic Approach -- The general implementation can be

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

Hi Guillaume, Thanks for the RFC. I'm generally +1 on the concept. Making bit field manipulation easier seems like a good overall goal given its prevalence in LLVM. As for the syntax, I tend to prefer that we don't pollute the namespace. Have you considered pushing the methods into the Bitfield class? Maybe something like: ``` uint8_t Storage = 0; using Amount =

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 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

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

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

On Sat, Feb 29, 2020 at 4:00 PM Nicholas Krause <xerofoify at gmail.com> wrote: > > > On 2/29/20 6:17 PM, River Riddle via llvm-dev wrote: > > > > On Sat, Feb 29, 2020 at 2:25 PM David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> >> On Sat, Feb 29, 2020 at 2:19 PM Chris Lattner <clattner at nondot.org> >>