[PATCH] D18634: Don't IPO over functions that can be de-refined

Mehdi Amini via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 31 10:24:50 PDT 2016


> On Mar 31, 2016, at 10:10 AM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
> 
> Mehdi Amini wrote:
> 
> > This is the part that is still not clear to me, I'd expect the logic
> > to be similar and the kind of query to be on the same level as 1-2-3
> > above. And the answer should be the same at the IR level as well as at
> > the backend level.
> >
> > For instance I think X86Subtarget::ClassifyGlobalReference is
> > interested in 1) above.
> 
> E.g., the mid level optimizer is not interested in differentiating
> between linkonce_odr and weak_odr, while the backend is (in
> llvm::canBeOmittedFromSymbolTable).
> 
> > That sounds "black magic", and it seems to me that you can't handle
> > this with predicates purely based on the linkage types. We'll probably
> > need another abstraction (in the function class) for that.
> 
> The (1), (2) and (3) above were supposed to be that abstraction.
> Would you rather that I moved them to the function class?

If you want this level of abstraction (and it would be a good thing I think), I'm saying you can't achieve this based purely on the linkage type (I hope I'm stating the obvious here, since you wrote that you wanted some function with a linkage type in 2) to be considered as 1) based on an attribute).
So we need something higher-level that  `predicate(LinkageType)`. Independently of the actual place location.
Maybe we need a new "IPAInfo" kind of class, that would implement a bunch of `predicate(GlobalValue *GV)`?



> 
> >> Thus, I see merit in keeping these two distinct views of of linkage
> >> types separated, even if there is some overlap in functionality.
> >>
> >> Right now the mapping for the "IR optimization" context is
> >>
> >> mayBeOverridden == (3)
> >> mayBeDerefined == (3) union (2)
> >> NOT(mayBeDerefined) == (1)
> >
> > Isn't it  "mayBeOverridden == (2)"?
> > (I ranted on IRC about how badly that named)
> 
> I can't see how; but I may have confused myself (here or on IRC).

You're totally right,  "mayBeOverridden == (3)". I misread the description for 3 the first time I think.

> > Ideally a good start would be to have the same "high level
> > description" as you did for backend purpose (CC Rafael and Eric
> > maybe).
> 
> Honestly, I doubt there is an over-arching high level description for
> the backend -- it seems to change its behavior based on specific
> linkage types (grep for 'has.*Linkage' in lib/Codegen).

If it is the case, I'd suggest to keep the backend separate and group in a single place the relevant set of predicates for IPA/IPO purposes.

-- 
Mehdi


More information about the llvm-commits mailing list