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

[Sanjoy Das via llvm-commits]

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?

 >> 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).

 > 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).

-- Sanjoy