Pete Cooper via llvm-dev
2015-Sep-14 21:31 UTC
[llvm-dev] RFC: speedups with instruction side-data (ADCE, perhaps others?)
> On Sep 14, 2015, at 2:28 PM, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > What is the contract between passes for the marker bit? I.e. do passes need to "clean up" the marker bit to a predetermined value after they run? (or they need to assume that it might be dirty? (like I think you do below))Good questions, and to add to this, what happens if we run passes in parallel? I can imagine a world where we run 2 function passes in parallel so tagging instructions is ok, but what if we then started to run 2 BB passes in parallel, or used the tag to track something like GlobalValue. Going to break horribly in such scenarios. Pete> > -- Sean Silva > > On Mon, Sep 14, 2015 at 9:37 AM, escha via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > I’ve been playing around with optimizing performance various passes and noticed something about ADCE: it keeps an Alive set that requires a lot of upkeep time-wise, but if each instruction had a /single bit/ of side data (to represent liveness, solely within the pass), the set wouldn’t be needed. I tested this out and observed a ~1/3 reduction in time in ADCE: 1454ms to 982ms according to a profile over our test suite (for a total of 0.6% compile time savings in our pipeline). > > Are there any other passes that could benefit from having a single bit (or similarly small amount) of per-Instruction metadata local to the pass, i.e. to avoid having to keep a side-Set of instructions that’s only used to test membership of the set (i.e. not iterated over)? Is this sort of thing something reasonable (maybe it could be stuffed in the SubclassData short and exposed via a public API?) > > —escha > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150914/6ee7a4b8/attachment.html>
Sean Silva via llvm-dev
2015-Sep-14 21:34 UTC
[llvm-dev] RFC: speedups with instruction side-data (ADCE, perhaps others?)
On Mon, Sep 14, 2015 at 2:31 PM, Pete Cooper <peter_cooper at apple.com> wrote:> > On Sep 14, 2015, at 2:28 PM, Sean Silva via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > What is the contract between passes for the marker bit? I.e. do passes > need to "clean up" the marker bit to a predetermined value after they run? > (or they need to assume that it might be dirty? (like I think you do below)) > > Good questions, and to add to this, what happens if we run passes in > parallel? > > I can imagine a world where we run 2 function passes in parallel so > tagging instructions is ok, but what if we then started to run 2 BB passes > in parallel, or used the tag to track something like GlobalValue. Going to > break horribly in such scenarios. >Do we ever plan to have two passes mutating the IR in parallel? I assume there would be much larger complications. -- Sean Silva> > Pete > > > -- Sean Silva > > On Mon, Sep 14, 2015 at 9:37 AM, escha via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I’ve been playing around with optimizing performance various passes and >> noticed something about ADCE: it keeps an Alive set that requires a lot of >> upkeep time-wise, but if each instruction had a /single bit/ of side data >> (to represent liveness, solely within the pass), the set wouldn’t be >> needed. I tested this out and observed a ~1/3 reduction in time in ADCE: >> 1454ms to 982ms according to a profile over our test suite (for a total of >> 0.6% compile time savings in our pipeline). >> >> Are there any other passes that could benefit from having a single bit >> (or similarly small amount) of per-Instruction metadata local to the pass, >> i.e. to avoid having to keep a side-Set of instructions that’s only used to >> test membership of the set (i.e. not iterated over)? Is this sort of thing >> something reasonable (maybe it could be stuffed in the SubclassData short >> and exposed via a public API?) >> >> —escha >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150914/c103e2de/attachment.html>
Pete Cooper via llvm-dev
2015-Sep-14 21:38 UTC
[llvm-dev] RFC: speedups with instruction side-data (ADCE, perhaps others?)
> On Sep 14, 2015, at 2:34 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > > On Mon, Sep 14, 2015 at 2:31 PM, Pete Cooper <peter_cooper at apple.com <mailto:peter_cooper at apple.com>> wrote: > >> On Sep 14, 2015, at 2:28 PM, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> What is the contract between passes for the marker bit? I.e. do passes need to "clean up" the marker bit to a predetermined value after they run? (or they need to assume that it might be dirty? (like I think you do below)) > Good questions, and to add to this, what happens if we run passes in parallel? > > I can imagine a world where we run 2 function passes in parallel so tagging instructions is ok, but what if we then started to run 2 BB passes in parallel, or used the tag to track something like GlobalValue. Going to break horribly in such scenarios. > > Do we ever plan to have two passes mutating the IR in parallel? I assume there would be much larger complications.Oh yeah, it would be a nightmare to find all the places to fix. So no idea if we’ll ever do it, but if we were going to, then this would make it even harder. Just want to make sure we’re ok with that. Personally I don’t like the idea of adding a bit to User to track this. If we don’t have the correct data structure to track this, then I feel like we should try write one… if thats even possible. Pete> > -- Sean Silva > > > Pete >> >> -- Sean Silva >> >> On Mon, Sep 14, 2015 at 9:37 AM, escha via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> I’ve been playing around with optimizing performance various passes and noticed something about ADCE: it keeps an Alive set that requires a lot of upkeep time-wise, but if each instruction had a /single bit/ of side data (to represent liveness, solely within the pass), the set wouldn’t be needed. I tested this out and observed a ~1/3 reduction in time in ADCE: 1454ms to 982ms according to a profile over our test suite (for a total of 0.6% compile time savings in our pipeline). >> >> Are there any other passes that could benefit from having a single bit (or similarly small amount) of per-Instruction metadata local to the pass, i.e. to avoid having to keep a side-Set of instructions that’s only used to test membership of the set (i.e. not iterated over)? Is this sort of thing something reasonable (maybe it could be stuffed in the SubclassData short and exposed via a public API?) >> >> —escha >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://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> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150914/06a78cd8/attachment.html>