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

[Sean Silva via llvm-dev]

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>