[llvm-dev] RFC: New aggressive dead code elimination pass

Daniel Berlin via llvm-dev llvm-dev at lists.llvm.org
Fri Mar 25 16:05:02 PDT 2016


On Fri, Mar 25, 2016 at 3:52 PM, Hal Finkel <hfinkel at anl.gov> wrote:

>
> ------------------------------
>
> *From: *"Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org>
> *To: *"Daniel Berlin" <dberlin at dberlin.org>
> *Cc: *"David Callahan via llvm-dev" <llvm-dev at lists.llvm.org>
> *Sent: *Friday, March 25, 2016 5:43:12 PM
> *Subject: *Re: [llvm-dev] RFC: New aggressive dead code elimination pass
>
>
> On Mar 25, 2016, at 3:30 PM, Daniel Berlin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> Make most things update post-dominance info and preserve it.
>
> Our other alternative to not take up too much time seems to be invasive
> surgery on how BB successors/predecessors work so they are a constant time
> array.  I say this because GCC recomputes post-dominators roughly 15-19
> times per compilation, and can do it about 3-5x faster than we can. All
> profiling i've done basically says all our time is spent trying to get at
> successors and predecessors in dominance/post-dominance respectively, which
> takes basically no time in gcc, because the edge lists are an array.
>
> (Note that if you look at generic dominance code, like
> http://www.cs.princeton.edu/~rwerneck/dominators/, it's much faster than
> what we do on the same graphs. This is true even though we use the same
> algorithms .....)
>
> Given it seems unlikely we are going to change the internal representation
> anytime soon (or at least i've not seen a proposal), updating post-dom
> seems the easier answer.
>
>
> Are we talking about the basic-blocks edges only? I'm not sure changing
> the IR for the BBs would be a lot more work than preserving dominance
> analysis everywhere, or I am totally underestimating one / overestimating
> the other?
>
>
> I'm also curious about this, especially because I'd naively think that:
>
>   representation change == a little thinking and (potentially) a lot of
> typing
>

It also may change space characteristics for programs with lots of edges.



>   preserving post dom == a lot of thinking and a little typing
>
> and, thus, while updating the analysis might be the *right* thing to do,
> it is probably not easier (especially once you factor in the time taken to
> fix bugs where we subtly get it wrong). Maybe in the long run, we should do
> both?
>

If we try to keep constant time edge redirection, both are fairly
complicated in terms of thinking :)


>
>  -Hal
>
> --
> Mehdi
>
>
>
>
>
> On Thu, Mar 24, 2016 at 11:56 PM, Eric Christopher <echristo at gmail.com>
> wrote:
>
>> What do you have in mind here?
>>
>> On Thu, Mar 24, 2016, 7:28 PM Daniel Berlin via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Yeah, that was gonna be my question.
>>> If so, my view is we should just bite the bullet and start threading
>>> post dominance through the compiler.
>>> (assuming anyone wants to help. I'm tackling the memoryssa updating
>>> stuff with george ATM).
>>>
>>>
>>>
>>> On Thu, Mar 24, 2016 at 7:04 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>>>
>>>> [+Danny]
>>>>
>>>> ------------------------------
>>>>
>>>> > From: "Justin Bogner via llvm-dev" <llvm-dev at lists.llvm.org>
>>>> > To: "David Callahan via llvm-dev" <llvm-dev at lists.llvm.org>
>>>> > Sent: Wednesday, March 23, 2016 12:36:50 PM
>>>> > Subject: Re: [llvm-dev] RFC: New aggressive dead code elimination pass
>>>> >
>>>> > David Callahan via llvm-dev <llvm-dev at lists.llvm.org> writes:
>>>> > > Hi,
>>>> > >
>>>> > > I have a new variant of Aggressive Dead Code Elimination that also
>>>> > > removes dead branching. It is designed to minimize the cost of
>>>> > > control-dependence analysis in the common case where almost the
>>>> > > entire
>>>> > > program is live. It also can optionally remove dead but
>>>> > > may-be-infinite loops.
>>>> > >
>>>> > > When enabled for –O3 (replacing current ADCE pass) and removing
>>>> > > loops,
>>>> > > impact on SPEC2006 is in the noise but it impacts internal
>>>> > > benchmarks
>>>> > > suites 1-2% with a comparable increase in compile time.  My
>>>> > > expectation would be to enable –O3 only until we have some
>>>> > > experience
>>>> > > with cost but I suspect it should be fine –O2.
>>>> >
>>>> > Just to clarify, you're saying that both runtime and compile time
>>>> > impact
>>>> > were in the noise on SPEC, right?
>>>> >
>>>> > > What information would the community like to see about such a
>>>> > > change
>>>> > > before I put up a diff and (including tweaks to unit tests).
>>>> >
>>>> > I'm not sure that there's much to discuss in the abstract - it's much
>>>> > easier to evaluate this kind of thing when there's a patch to refer
>>>> > to.
>>>> > Presumably people will want to try the patch out on their own
>>>> > internal
>>>> > benchmarks as well.
>>>>
>>>> +1
>>>>
>>>> Does it use post-dominance information?
>>>>
>>>>  -Hal
>>>>
>>>> >
>>>> > > Thanks
>>>> > > david
>>>> > > _______________________________________________
>>>> > > 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
>>>> >
>>>>
>>>> --
>>>> Hal Finkel
>>>> Assistant Computational Scientist
>>>> Leadership Computing Facility
>>>> Argonne National Laboratory
>>>>
>>>
>>> _______________________________________________
>>> 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
>
>
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160325/dc429f63/attachment.html>


More information about the llvm-dev mailing list