This is an archive of the discontinued LLVM Phabricator instance.

Option to ignore llvm[.compiler].used uses in hasAddressTaken()
ClosedPublic

Authored by rampitec on Feb 4 2021, 3:58 PM.

Diff Detail

Event Timeline

rampitec created this revision.Feb 4 2021, 3:58 PM
rampitec requested review of this revision.Feb 4 2021, 3:58 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 4 2021, 3:58 PM
Herald added a subscriber: wdng. · View Herald Transcript
rampitec updated this revision to Diff 321616.Feb 4 2021, 4:44 PM
madhur13490 added inline comments.Feb 9 2021, 10:54 AM
llvm/lib/Analysis/CallGraph.cpp
85

Typo: Ingore

llvm/lib/IR/Function.cpp
1619

Can you please add a test which has non-bitcast value of function pointers? Something like below;

@llvm.used = appending global [2 x float()*] [void()* @foo, void()* @bar]

IIRC, the above simple cast to GlobalVariable is not sufficient in this case. You need to handle it with some more extra checks.

rampitec updated this revision to Diff 322456.Feb 9 2021, 11:24 AM
rampitec marked an inline comment as done.

Fixed typo.

rampitec added inline comments.Feb 9 2021, 11:26 AM
llvm/lib/IR/Function.cpp
1619

Does this really happen? My understanding these arrays shall have i8* type, so a function pointer always needs a bitcast.

rampitec updated this revision to Diff 322511.Feb 9 2021, 2:55 PM
rampitec marked an inline comment as done.

Handle the case when function pointer is used directly.

(Passing comment not really related to the patch, but I wonder how hard / useful it would be to convert @llvm.used and @llvm.compiler.used to attributes (or similar)...?)

(Passing comment not really related to the patch, but I wonder how hard / useful it would be to convert @llvm.used and @llvm.compiler.used to attributes (or similar)...?)

At the very least these variables are defined in the LLVM IR specification, so it would be a compatibility break.

(Passing comment not really related to the patch, but I wonder how hard / useful it would be to convert @llvm.used and @llvm.compiler.used to attributes (or similar)...?)

At the very least these variables are defined in the LLVM IR specification, so it would be a compatibility break.

Right, it'd certainly be a semantic change; we'd need an auto-upgrade for bitcode (surely no compatibility break there) and a transition of some sort for the C API (I imagine there's a reasonable way of handling both, but maybe you're seeing some difficulty?). Probably it could / should be modelled as part of the linkage somehow, rather than an attribute, but it might not be worth a bit on Value. (But probably this isn't the right venue to discuss this; carry on...)

madhur13490 added inline comments.Feb 9 2021, 11:35 PM
llvm/lib/IR/Function.cpp
1583–1584

Need to enhance this comment to accommodate new arguments.

1588

%s/Ingore/Ignore

1619

Yes, as per the spec, "This array contains a list of pointers to named global variables, functions and aliases which may optionally have a pointer cast formed of bitcast or getelementptr". So the pointer cast is optional. You can have plain function pointers in the array. The newly added code will handle only bitcast cast case but not general. You need to handle the general case and find if one of the users if GlobalVariable.

@llvm.used = appending global [2 x void()*] [void()* @foo, void()* @bar]
rampitec updated this revision to Diff 322720.Feb 10 2021, 9:53 AM
rampitec marked 2 inline comments as done.

Fixed typo.

llvm/lib/IR/Function.cpp
1619

This is already done in the previous patch. I still think that does not practically happen because you cannot have elements of different types in an array. The words "may optionally have a pointer cast" shall apply if your pointer is not of the i8* type (since this variable is not only used for functions). For sure one can artificially forge such initializer (like I did in the test), but that does not have much practical sense.

madhur13490 added inline comments.Feb 12 2021, 3:37 AM
llvm/lib/IR/Function.cpp
1619

Two questions:

  1. I don't understand why the below the initialization of llvm.used is invalid?
@llvm.used = appending global [2 x void()*] [void()* @foo, void()* @bar]

I don't see verifier complain about it, which make me believe that it is a valid LLVM construct. Are you saying that it is not common so you'd like to skip it?

  1. Assumming that 1 is valid, does the patch succeed to determine if one of the user of function symbol is GlobalVariable?
rampitec added inline comments.Feb 12 2021, 9:54 AM
llvm/lib/IR/Function.cpp
1619
  1. The initialization is not invalid, it just useless. If you have functions with different types in a module you will not be able to to initialize it. You also will be unable link different modules with such initializations.
  2. Yet it works with the patch. See the test for llvm.compiler.used.
madhur13490 accepted this revision.Feb 12 2021, 10:09 AM

Accept with the condition that the comment is enhanced.

This revision is now accepted and ready to land.Feb 12 2021, 10:09 AM
rampitec updated this revision to Diff 323385.Feb 12 2021, 10:16 AM

Updated comment.