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

[Hal Finkel via llvm-dev]

----- Original Message ----- 

> From: "Owen Anderson via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "Mehdi Amini" <mehdi.amini at apple.com>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Tuesday, September 15, 2015 4:16:58 PM
> Subject: Re: [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?

Are these actually free bits, or does this increase the size of Value? If they're free, how many free bits do we have in Value and does this differ on common 32-bit and 64-bit systems?

Also, this:

> I should note, when I was writing my simplifyInstructionsInBlock
> replacement, I got a similarly large speedup (~1000ms -> 700ms) with
> the trick where I only added instructions to the worklist if they
> needed to be /revisited/, as opposed to initting the entire worklist
> with all the instructions. This is likely a similar gain as to what
> I got here because it’s the difference between “put everything in
> the function in a set” and “putting only a few things from the
> function in a set”, so the gain from Not Putting Tons Of Stuff In A
> Set seems to be pretty consistent across widely varying use-cases.

Can this be generalized to other relevant use cases?

 -Hal

> —Owen
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

> --
Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-- 
Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory