[LLVMdev] Best way to clean up empty global_ctors

[Richard Smith]

On Thu, May 1, 2014 at 1:01 PM, Nick Lewycky <nlewycky at google.com> wrote:

> On 1 May 2014 11:12, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>
>> On 1 May 2014 14:08, Reid Kleckner <rnk at google.com> wrote:
>> > I talked about this with Nick in person months ago, and my
>> understanding is
>> > that GlobalOpt is also an enabling optimization that needs to run early.
>> > For example, if we can eliminate an initializer to an internal global
>> with
>> > no other stores to it, we can propagate the result.
>> >
>> > Maybe we should run it twice.
>>
>> That is probably fine, we just have to make sure compile time doesn't
>> surfer too much.
>>
>
> There are many cases where another run of globalopt at the end would clean
> things up.
>
> I have a few concerns. One is that globalopt can miscompile, and I'm
> afraid of making it do more or learn new tricks because that may expose its
> miscompiley underbelly. The second is that a late run of globalopt opens up
> all manner of new opportunities for the rest of the scalar optimizers,
> which we don't run again. That's a sign that we should be designing it
> differently, I just haven't thought about how exactly.
>

OK, you've said you don't want to teach globalopt any new tricks, so I'm
going to suggest teaching it a new trick ;)

If globalopt sees the load of a variable but doesn't have a definition of
that variable, could it succeed and track that it has an unusable value
(but fail if that value is actually used anywhere)? This is perhaps just
addressing the symptom rather than the root cause, but it'd work for this
case (where the only reason globalopt can't symbolically execute the
function is because it loads and ignores an undefined global).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140501/7aa49670/attachment.html>