[llvm-dev] Interprocedural DSE for -ftrivial-auto-var-init

[Amara Emerson via llvm-dev]

Can you post numbers for how many stores get eliminated from CTMark?

> On Apr 16, 2019, at 11:45 AM, Vitaly Buka <vitalybuka at google.com> wrote:
> 
> I tried -Os and effect of new approach significantly increases.
> I run regular DSE and immediately myDSE. With -Os myDSE removes more than 50% of DSE number.
> Which is expected as -Os inlines less and regular DSE can't remove over function call.
> 
> On Tue, Apr 16, 2019 at 7:11 AM Alexander Potapenko <glider at google.com <mailto:glider at google.com>> wrote:
> On Mon, Apr 15, 2019 at 11:02 PM Amara Emerson via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >
> >
> > > On Apr 15, 2019, at 1:51 PM, Vitaly Buka via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> > >
> > > Hi JF,
> > >
> > >    I've heard that you are interested DSE improvements and maybe we need to be in sync.
> > >    So far I experimented with following DSE improvements:
> > >
> > > * Cross-block DSE, it eliminates additional 7% stores comparing to existing DSE. But it's not visible on benchmarks.
> > I take it you couldn’t see any runtime impact? If there’s code size improvements that could also be useful, CTMark in the llvm test suite is a useful subset of benchmarks to check this on (as a baseline use -Os to compare code size).
> >
> > Thanks,
> > Amara
> > >
> > > * Cross-block + Interprocedural analysis to annotate each function argument with:
> > >   - can read before write
> > >   - will always write
> > > This annotations gets me 20% stores deleted additional to the current DSE.
> I believe we can only benefit from removing extra stores.
> Hot functions in existing benchmarks are probably optimized good
> enough already, but speeding up the long tail is also important.
> Also, at least the repro in
> https://bugs.llvm.org/show_bug.cgi?id=40527 <https://bugs.llvm.org/show_bug.cgi?id=40527> has been extracted from a
> real kernel benchmark (hackbench), where this extra store costed us
> 0.45%
> 
> > > This is on LLVM codebase with -ftrivial-auto-var-init=patter.
> > >
> > > As-is it's less than I expected, so I would like to find good benchmark to decide if we should work to make production code from my experiment.
> > >
> > > So now I am also planing to try to extend that to whole program analysis.
> > > I will cleanup my code and upload this during this weak, if anyone wants to try.
> > >
> > > Vitaly.
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> 
> 
> -- 
> Alexander Potapenko
> Software Engineer
> 
> Google Germany GmbH
> Erika-Mann-Straße, 33
> 80636 München
> 
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190416/875f6cc0/attachment.html>