This is an archive of the discontinued LLVM Phabricator instance.

Introduce GlobalAlias::mayBeResolved().
Needs ReviewPublic

Authored by pcc on Apr 1 2013, 2:08 PM.
This revision needs review, but there are no reviewers specified.

Details

Reviewers
None
Summary

This controls whether the aliasee may be used instead of the alias.
Normally the same as mayBeOverridden(), except in the case where the
alias's visibility differs from the aliasee, as the visibility controls
whether accesses use the global offset table (which can be important).

Diff Detail

Event Timeline

asl added a comment.Apr 1 2013, 2:19 PM

I'm not sure that changing mayBeOverriden() to mayBeResolved() everywhere is fine. E.g. change to getUnderlyingObject() might not be correct. Ditto for SCEV / Inliner changes.

Needs a testcase.

I don' think "may" is the best term in here. Resolving an alias should be legal. It only causes problem in very special cases (like the got not being available yet ). The question is if it is profitable to do so.

In the globalopt case it is not. I have not investigated what the other passes are doing.

pcc updated this revision to Unknown Object (????).May 20 2013, 8:54 AM
  • Add test case
pcc added a comment.May 20 2013, 8:54 AM

Needs a testcase.

Hmm. I wonder where the test case should live, then. The purpose of the test case should be to check that no (standard) pass resolves the alias, so I don't think it should belong to a specific pass, such as globalopt. For now I added it under test/Other. (Existing globalopt tests already check that aliases are resolved when they should be, so my test only checks that aliases aren't resolved when they shouldn't be.)

I don' think "may" is the best term in here. Resolving an alias should be legal. It only causes problem in very special cases (like the got not being available yet ). The question is if it is profitable to do so.

Well, the choice of whether to resolve an alias can also affect the semantics of symbol interpositioning. While we normally don't care about interpositioning semantics, I think that if the user has gone to the trouble of creating an alias whose visibility differs from the aliasee, that's a pretty strong signal that the user cares about those semantics, and we should respect the user's wishes.

rafael added inline comments.Jul 2 2013, 6:46 AM
include/llvm/IR/GlobalAlias.h
82

I would still prefer to state this as a profitability issue. We really don't model interposition of non weak symbols, and a partial implementation would do more harm than good IMHO.

In particular, please call this function something like shouldBeResolved or isProfitableToResolve. The function should also return true if the Aliasee is "more hidden" than the alias.

test/Other/alias-resolution.ll
2

This is a reasonable use of -O3. Please just add a comment saying why (we want to make sure no pass resolves the alias).

I like the idea. 7 years have passed... We still miss the optimization opportunity:

int _rtld_global;
extern int _rtld_local __attribute__((visibility("hidden"), alias("_rtld_global")));

int get() { return _rtld_local; }

gcc -fPIC -O3 -fno-common -c a.c => R_X86_64_PC32
clang -fPIC -O3 -fno-common -c a.c => R_X86_64_GOTPCREL