Vitaly Buka via llvm-dev
2019-Apr-15 20:51 UTC
[llvm-dev] Interprocedural DSE for -ftrivial-auto-var-init
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. * 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. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190415/a0fa0bb7/attachment.html>
JF Bastien via llvm-dev
2019-Apr-15 20:55 UTC
[llvm-dev] Interprocedural DSE for -ftrivial-auto-var-init
> On Apr 15, 2019, at 1:51 PM, Vitaly Buka <vitalybuka at google.com> 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. > > * 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. > > 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.This is great! I’ll try out the patches when you post them, and see if it resolves the issues I’d been seeing. I don’t think we need benchmark gains fro this to be worthwhile since variable auto-init adds slightly unusual code. I think it’s aggravating cases where current DSE was failing in innocuous ways.
Amara Emerson via llvm-dev
2019-Apr-15 21:02 UTC
[llvm-dev] Interprocedural DSE for -ftrivial-auto-var-init
> On Apr 15, 2019, at 1:51 PM, Vitaly Buka via llvm-dev <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. > > 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 > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Alexander Potapenko via llvm-dev
2019-Apr-16 14:11 UTC
[llvm-dev] Interprocedural DSE for -ftrivial-auto-var-init
On Mon, Apr 15, 2019 at 11:02 PM Amara Emerson via llvm-dev <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> 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 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 > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > 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
Possibly Parallel Threads
- Interprocedural DSE for -ftrivial-auto-var-init
- Interprocedural DSE for -ftrivial-auto-var-init
- Interprocedural DSE for -ftrivial-auto-var-init
- Dead store elimination in the backend for -ftrivial-auto-var-init
- Dead store elimination in the backend for -ftrivial-auto-var-init