search for: machineoutliner

> Just chiming in about the outliner stuff. (In general, I think it's desirable to have multiple options for how early/late a pass runs.) I'm wondering if MachineOutliner can be augmented to add MachineFunctionSplitter functionalities as well. If the analysis part of MachineOutliner can allow single basic block outlining with some cost models. Aditya Kumar Compiler Engineer https://bitsimplify.com -------------- next part -------------- An HTML attachment was scrub...

Teaching the back end about size optimization sounds great, even without the exciting work on MachineOutliner. It would strip some nasty hacks from an out of tree back end that cares about code size :) Thank you > The first patch is one that teaches the backend about size optimization > levels. This is comparable to what's done in the inliner. Today, the only > way to tell if something is o...

...> Of course, I don’t expect you to do that :). What I meant is that the > claim that IR offers the better trade off is not based on hard evidences. I > actually don’t buy it. > > My point was to make sure I understand what you are trying to solve and > given you have mentioned the MachineOutliner, why you are not working on > improving it instead of suggesting a new framework. > Don’t take me wrong, maybe creating a new framework at the IR level is the > right thing to do, but I still didn’t get that from your comments. > > There are several comparison benchmarks given in the...

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

...gt; - A cost model > > I don’t think it’d be too difficult to split it up in that sort of way. I’d also like to experiment with pre-regalloc outlining in general, so it’d make it easier to explore that route as well. > >> 1. if you run the LLVM IR level code size outliner, then the MachineOutliner fails to find any significant redundancies. >> >> 2. if you run the LLVM IR level code size outliner, then the MachineOutliner finds just as many redundancies. > > This would be interesting. The MachineOutliner deems two instructions equivalent iff their opcodes and operands are...

Hi Yvan, On Mon, 5 Nov 2018 at 10:11, Yvan Roux via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Yes, I'll submit an RFC soon, my prototype works fine but I still have > a couple issues to tackle (some Thumb1 corner cases, PIC code > generation, ...) and enhance the testsuite. Any news on this? I'm starting to look into 32-bit ARM outlining too and could probably help

> Porting the outliner on ARM is in my plans for this year (as discussed > with other ARM folks at EuroLLVM last week), to avoid duplication is > it ok for you if I work on it, David, Jessica ? Yeah, sounds great to me. I had merely got as far as looking at the AArch64 code to see how easy it would be to copy, without any honest expectation of being able to look into it properly any time

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

> Porting the outliner on ARM is in my plans for this year (as discussed > with other ARM folks at EuroLLVM last week), to avoid duplication is > it ok for you if I work on it, David, Jessica ? Sounds good to me; an ARM target would be great! - Jessica > On Apr 26, 2018, at 2:17 AM, Yvan Roux <yvan.roux at linaro.org> wrote: > > Hi, > > On 25 April 2018 at

...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 > repeated sequences. > > The MachineOutliner currently has an “InstructionMapper” struct in it. I > think we can probably build on that struct so that we can choose different > mapping schemes. > > (3) Cost model/candidate selection scheme > > Every outliner should implement a function that returns the outlining cost > or...

...ic for value numbering > in your current scheme. If you do, and you plan to share more code > between IR and MI outliner, then it's a good idea I guess to have a > common interface (I'd love to hear your thoughts on this one). Absolutely. There are plenty of opportunities that the MachineOutliner misses due to simple things like register allocation, on top of things like the example you gave. A more powerful scheme, and moving the MachineOutliner pre-regalloc would be highly beneficial. Having a common interface here would be great. (This would be a really interesting way to analyze the ove...

...e backend about size > optimization levels. This is comparable to what's done in the inliner. > Today, the only way to tell if something is optimizing for size is by > looking at function attributes. This is fine for function passes, but > insufficient for module passes like the MachineOutliner. The function > attribute approach forces the outliner to iterate over every function > in the module before deciding to take action. If -Oz isn't passed in, > then the outliner will not find any functions worth outlining from. > This would incur unnecessary compile-time overhea...

...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 repeated sequences. The MachineOutliner currently has an “InstructionMapper” struct in it. I think we can probably build on that struct so that we can choose different mapping schemes. (3) Cost model/candidate selection scheme Every outliner should implement a function that returns the outlining cost or benefit of a candidate. In the M...

...> >> 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 >> repeated sequences. >> >> The MachineOutliner currently has an “InstructionMapper” struct in it. I >> think we can probably build on that struct so that we can choose different >> mapping schemes. >> >> (3) Cost model/candidate selection scheme >> >> Every outliner should implement a function that returns...

...h is one that teaches the backend about size optimization levels. This is comparable to what's done in the inliner. Today, the only way to tell if something is optimizing for size is by looking at function attributes. This is fine for function passes, but insufficient for module passes like the MachineOutliner. The function attribute approach forces the outliner to iterate over every function in the module before deciding to take action. If -Oz isn't passed in, then the outliner will not find any functions worth outlining from. This would incur unnecessary compile-time overhead. Thus, we decided the...

...h is one that teaches the backend about size optimization levels. This is comparable to what's done in the inliner. Today, the only way to tell if something is optimizing for size is by looking at function attributes. This is fine for function passes, but insufficient for module passes like the MachineOutliner. The function attribute approach forces the outliner to iterate over every function in the module before deciding to take action. If -Oz isn't passed in, then the outliner will not find any functions worth outlining from. This would incur unnecessary compile-time overhead. Thus, we decided the...

...level optimizations, including inlining. As for the worry about code size regressions, so far the results seem to support our hypothesis. Thanks, River Riddle On Mon, Jul 24, 2017 at 11:12 AM, Jessica Paquette <jpaquette at apple.com> wrote: > > Hi River, > > I’m working on the MachineOutliner pass at the MIR level. Working at the > IR level sounds interesting! It also seems like our algorithms are similar. > I was thinking of taking the suffix array route with the MachineOutliner in > the future. > > Anyway, I’d like to ask about this: > > On Jul 20, 2017, at 3:47 P...

One place to look might be in the MachineOutliner target hooks in X86InstrInfo and AArch64InstrInfo. The MachineOutliner runs extremely late in the pass pipeline so it might be a good place to look for some inspiration. Of course, because this is *extremely late* it might not do *exactly* what you need. (e.g, this is post-register allocation, post...

...s comparable to what's done in the >>>> inliner. Today, the only way to tell if something is optimizing for >>>> size is by looking at function attributes. This is fine for >>>> function passes, but insufficient for module passes like the >>>> MachineOutliner. The function attribute approach forces the >>>> outliner to iterate over every function in the module before >>>> deciding to take action. If -Oz isn't passed in, then the outliner >>>> will not find any functions worth outlining from. This would incur &...

...as you describe and would thus deserve more discussion. > > Cheers, > -Quentin > > Thanks, > River Riddle > > On Mon, Jul 24, 2017 at 11:12 AM, Jessica Paquette <jpaquette at apple.com> > wrote: > >> >> Hi River, >> >> I’m working on the MachineOutliner pass at the MIR level. Working at the >> IR level sounds interesting! It also seems like our algorithms are similar. >> I was thinking of taking the suffix array route with the MachineOutliner in >> the future. >> >> Anyway, I’d like to ask about this: >> >&gt...