llvm dev - Sep 2015 - 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

> 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

> 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

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