This is the mail archive of the
mailing list for the GCC project.
Re: At linktime, consider linkonces as ones that will go away
> > The difference in between cgraph_can_remove_if_no_direct_calls_p and
> > cgraph_can_remove_if_no_direct_calls_and_refs_p is whether pass cares of
> > indirect calls too. I could make ipa-inline to use
> > cgraph_can_remove_if_no_direct_calls_and_refs_p and test if address is
> > taken, but since the former existed longer and I think it could be
> > useful elsewhere I decided to keep it.
> What's completely confusing is, why _and_refs does _not_ take into account
> node.address_taken. After all if the address is taken (from whereever) we
> can not remove the function (no matter if no direct calls, or other refs,
> or anything else remains or can be ignored), but still
> cgraph_can_remove_if_no_direct_calls_and_refs_p could return true.
Because of "and_refs_p". Refs reffers to ipa-ref references that includes all
places function has addess taken.
Unreachable function removal is usual mark&sweep algorithm. We start with
functions/vars that are not removable even if all direct calls and references
disappear and mark everything referenced or called from that. If it was part
of this algorithm only, I would probably call it "trivially_needed_node_p" (or
obviously_neccesary_node_p as tree-ssa-dce does), but this name has no meaning
outside context of mark&sweep.
Name is not exact WRT comdat groups (it is older than comdat group code),
basically you are asking:
"If I arrange the following:
1) no direct calls to FN
2) no references to FN (if use and_refs_p variant)
3) all functions within the same comdat group must meet
cgraph_can_remove_if_no_direct_calls_and_refs_p, 1) and 2)
can I remove function FN from the compilation unit then?"
(As a historical note, this is reason why "needed" flag on cgraph nodes exist
and is named this way. It however turned out that notion of neededness change
during compilatoin. First difference is whether we are finalizing source code
unit or compilation unit, second difference makes whole program and third
difference if we are before or after inlining. Before inlining all extern
inline functions that are referenced or called are not removed, while after
inlining all of those are removable from current unit. With devirutalization
this is even funnier, since we want to also hold those)
> The two _can_remove (and the new one) are confusing
> because they seem to be strange conditional predicates, where certain
> conditions are established at the callers of those predicates and I have
> a hard time figuring out what those conditions are exactly, and why the
> predicates are named in a way that doesn't reflect what they say, and why
> there are different such sets of condition (requiring different can_remove
Well, the predicates must be conditional, so they are called so.
In dead code removal neither other places we can't first do the transforms
and then ask if function disappeared, because decision on what transforms
you do depends if you will end up removing that function or not.
> > The new predicate is used in cases where you want to see if doing code
> > duplication eliminating direct calls to given function will make the
> > function to disappear from program (not only current unit as
> > cgraph_can_remove_if_no_direct_calls_p). So it is useful for metrics
> > deciding on how those transforms affect program size, but not for actual
> > removal of function.
> Okay, so the _from_program in your initial name did make sense (as in
> different to a hypothetical _from_unit). So my
> cgraph_remove_from_program_p suggestion still stands. You could then at
> least rename cgraph_can_remove_if_no_direct_calls_p into
> cgraph_remove_from_unit_p (and I hope that remove_from_program
> implies remove_from_unit).
Well, remove_from_program_p would read for me as question
"shall I remove function FN form the program now?"
This is not how it works...
> As this is the only user of cgraph_can_remove_if_no_direct_calls_p() the
> last test (!e->callee->same_comdat_group) can be merged into the predicate
> itself. After all, it does belong into it: with inliner being
> stupid we cannot remove the function if e->callee->same_comdat_group.
Well, I do not want more divergence in between those two predicates than
what their name suggest. In my Czenglish I would end up with
Thanks for suggestions, I was always having concerns that many various
functions with stuble semantics differences makes cgrpah code difficult to
read. So suggestions are welcome ;)