Pete Cooper via llvm-dev
2015-Sep-14 21:58 UTC
[llvm-dev] RFC: speedups with instruction side-data (ADCE, perhaps others?)
> On Sep 14, 2015, at 2:49 PM, Matt Arsenault via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 09/14/2015 02:47 PM, escha via llvm-dev wrote: >> I would assume that it’s just considered to be garbage. I feel like any sort of per-pass side data like this should come with absolute minimal contracts, to avoid introducing any more inter-pass complexity. > I would think this would need to be a verifier error if it were ever non-0+1 Otherwise every pass which ever needs this bit would have to first zero it out just to be safe, adding an extra walk over the whole functions. Of course otherwise the pass modifying it will have to zero it, which could also be a walk over the whole function. So either way you have lots iterate over, which is why i’m weary of this approach tbh.> _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
escha via llvm-dev
2015-Sep-14 22:25 UTC
[llvm-dev] RFC: speedups with instruction side-data (ADCE, perhaps others?)
> On Sep 14, 2015, at 2:58 PM, Pete Cooper <peter_cooper at apple.com> wrote: > > >> On Sep 14, 2015, at 2:49 PM, Matt Arsenault via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On 09/14/2015 02:47 PM, escha via llvm-dev wrote: >>> I would assume that it’s just considered to be garbage. I feel like any sort of per-pass side data like this should come with absolute minimal contracts, to avoid introducing any more inter-pass complexity. >> I would think this would need to be a verifier error if it were ever non-0 > +1 > > Otherwise every pass which ever needs this bit would have to first zero it out just to be safe, adding an extra walk over the whole functions.My ADCE patch doesn’t need an extra walk over the function; it just marks them as Alive or Not Alive during the first walk. —escha
Mehdi Amini via llvm-dev
2015-Sep-15 00:02 UTC
[llvm-dev] RFC: speedups with instruction side-data (ADCE, perhaps others?)
> On Sep 14, 2015, at 2:58 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > >> On Sep 14, 2015, at 2:49 PM, Matt Arsenault via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On 09/14/2015 02:47 PM, escha via llvm-dev wrote: >>> I would assume that it’s just considered to be garbage. I feel like any sort of per-pass side data like this should come with absolute minimal contracts, to avoid introducing any more inter-pass complexity. >> I would think this would need to be a verifier error if it were ever non-0 > +1 > > Otherwise every pass which ever needs this bit would have to first zero it out just to be safe, adding an extra walk over the whole functions. > > Of course otherwise the pass modifying it will have to zero it, which could also be a walk over the whole function. So either way you have lots iterate over, which is why i’m weary of this approach tbh.Every pass which ever uses this internally would have to set it to zero when it is done, adding an extra walk over the whole functions as you noticed. This goes against “you don’t pay for what you don’t use”, so definitively -1 for this. Better to cleanup before use. I agree that the approach does not scale/generalize well, and we should try to find an alternative if possible. Now *if* it is the only way to improve performance significantly, we might have to weight the tradeoff. — Mehdi
Owen Anderson via llvm-dev
2015-Sep-15 21:16 UTC
[llvm-dev] RFC: speedups with instruction side-data (ADCE, perhaps others?)
> On Sep 14, 2015, at 5:02 PM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> >> On Sep 14, 2015, at 2:58 PM, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >>> On Sep 14, 2015, at 2:49 PM, Matt Arsenault via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On 09/14/2015 02:47 PM, escha via llvm-dev wrote: >>>> I would assume that it’s just considered to be garbage. I feel like any sort of per-pass side data like this should come with absolute minimal contracts, to avoid introducing any more inter-pass complexity. >>> I would think this would need to be a verifier error if it were ever non-0 >> +1 >> >> Otherwise every pass which ever needs this bit would have to first zero it out just to be safe, adding an extra walk over the whole functions. >> >> Of course otherwise the pass modifying it will have to zero it, which could also be a walk over the whole function. So either way you have lots iterate over, which is why i’m weary of this approach tbh. > > Every pass which ever uses this internally would have to set it to zero when it is done, adding an extra walk over the whole functions as you noticed. This goes against “you don’t pay for what you don’t use”, so definitively -1 for this. Better to cleanup before use. > I agree that the approach does not scale/generalize well, and we should try to find an alternative if possible. Now *if* it is the only way to improve performance significantly, we might have to weight the tradeoff.Does anyone have any concrete alternative suggestions to achieve the speedup demonstrated here? —Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150915/b6c7d7ff/attachment.html>