llvm dev - Sep 2015 - RFC: speedups with instruction side-data (ADCE, perhaps others?)

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.

—escha
> On Sep 14, 2015, at 2:28 PM, Sean Silva <chisophugis at gmail.com>
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))
> 
> -- 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>
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150914/441edf37/attachment.html>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150914/8c334678/attachment.html>

> 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