PATCH: don't mark pure derived method odr because of a qualified call to base method

[Chandler Carruth]

Rerunning the optimization pipeline after adding new function definitions
will do bad things... It would cause the inliner and globalopt to make
strange and suboptimal decisions....
On Feb 13, 2013 4:18 PM, "John McCall" <rjmccall at apple.com> wrote:

> On Feb 13, 2013, at 3:40 PM, Nick Lewycky <nlewycky at google.com> wrote:
>
> On 13 February 2013 10:53, John McCall <rjmccall at apple.com> wrote:
>
>> On Feb 13, 2013, at 12:53 AM, Nick Lewycky <nlewycky at google.com> wrote:
>> > Thinking about this issue more, I'd like to retract this patch.
>> Consider the case where we're implementing the rule that all ODR-used
>> inline functions must have a definition. If Derived::fn is marked inline,
>> we'll see a fictitious use of it and reject a valid translation unit.
>> >
>> > My next plan is to remove this code from Sema entirely and do the
>> equivalent work inside codegen proper. No reason it can't keep track of
>> probable virtual function targets when writing out a virtual dispatch.
>>
>> Ugh.  I am not thrilled by the idea of emitting massive amounts of code
>> because something *might* devirtualize to it.
>>
>> Also, this potentially requires template instantiation.
>>
>
> Me neither. However, Sema and CodeGen are already colluding to do this.
> See SemaExpr.cpp:11168 (MarkExprReferenced), which may trigger
> instantiation, and CGExprCXX.cpp:200 (EmitCXXMemberCallExpr) which assumes
> the potential callee was already instantiated.
>
>
> If we're willing to break some of the majestic beauty of the
> frontend-isolated optimizer, we could queue up a late module pass which
> 1) recognizes that we've emitted a reference to something that we're
> required to define in every translation unit that references it (easy to do
> with metadata),
> 2) goes back to Sema and IR-gen to produce that code, and
> 3) restarts the optimizer on the new functions.
> Repeat until hopefully-rapid convergence.
>
> John.
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130213/b1ce501b/attachment.html>