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

[Eric Christopher via llvm-dev]

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]
>>
>> ----- Original Message -----
>> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160325/90644dbc/attachment.html>