similar to: [RFC] Interprocedural MIR-level outlining pass

I think the "Motivation" section explained that. I too first thought about "why not at IR?" but the reason looks like MIR, post-RA has the most accurate heuristics (best way to know looks like actually getting there). Do you know if there is any experimental pass that relies on deriving heuristics by a feedback loop after letting, ie. a duplicate module/function/block continue

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

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

Daniel, OK, I see your point. My understanding was that VNDAG is an internal representation, not meant to be used by VN's customers (that should really care for classes of congruency, nothing more). Also, I thought that VN's results are available for a single function at a time. It seems that NewGVN provides access to VNDAGs computed for the whole program -- which enables its usage in

Hi Violeta, I compiled with clang -Oz and clang -Oz -mno-red-zone for comparisons against Oz and clang -O0 and clang -O0 -mno-red-zone for comparisons against a default clang. I unfortunately don’t have the clang commit I worked with on my home laptop, and don’t have access to the computer I was using at Apple, so I can’t help you there. Jessica > On Sep 28, 2016, at 11:22 AM, Violeta

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

> 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 Eli, > I just tried some tests, and I'm seeing a bunch of failures on SPEC at -O3; looks like mostly crashes at runtime. I can try to reduce a testcase if you need it. If you could do that, that would be great. Our testing has been primarily for -Oz and -O2, so I haven’t looked at -O3 at all. > I don't think this is really the right approach. With LTO, you can have a mix of

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

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;

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

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

Hello A 4.4% geomean codesize improvement is really impressive. That stuff is hard to come by, you usually have to nibble away at it bit at a time. I ran some codesize benchmarks we have and they were in the same ballpark. Some of these are quite small so had less opportunity for outlining, but the average was still over 3% with some as high as 9-10%. All the tests I ran were fine, although we

On 4/20/2018 7:06 PM, Jessica Paquette via llvm-dev wrote: > We perform regular testing to ensure the outliner produces correct > AArch64 code at -Oz. Tests include the LLVM test suite and standard > external test suites such as SPEC. All tests compile and > execute. We've also been making sure that the outliner produces > debuggable code. Users are still guaranteed to have

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,

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 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 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, On 25 April 2018 at 14:02, David Green via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Hello > > A 4.4% geomean codesize improvement is really impressive. That stuff is hard to come by, you usually have to nibble away at it bit at a time. I ran some codesize benchmarks we have and they were in the same ballpark. Some of these are quite small so had less opportunity for