[PATCH] D98884: [IR] Ignore bitcasts of function pointers which are only used as callees in callbase instruction

Stanislav Mekhanoshin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 26 11:05:56 PDT 2021


rampitec added a comment.

In D98884#2653399 <https://reviews.llvm.org/D98884#2653399>, @madhur13490 wrote:

> In D98884#2653366 <https://reviews.llvm.org/D98884#2653366>, @rampitec wrote:
>
>> In D98884#2653361 <https://reviews.llvm.org/D98884#2653361>, @madhur13490 wrote:
>>
>>> In D98884#2653291 <https://reviews.llvm.org/D98884#2653291>, @rampitec wrote:
>>>
>>>> This should work I guess. It needs tests for non-callee use and non call base uses. I would also prefer to GlobalOpt change to be extracted into a separate patch.
>>>
>>> non call base users - What all such cases possible?We can use invoke but that is also CallBase.
>>
>> That is more than possible. Take a pointer and store it, compare to another pointer, bitcast and store or compare.
>
> Yes, but we should also consider about hasAddressTaken(). I am now starting to think if hasAddressTaken() needs to be more matured. Technically, you can cast a function pointer to global i8* and do all operations you suggest (e.g. use it as an operand in load) but hasAddressTaken() would return true in such cases because I am considering only CallBase users. If it needs to be more matured then we need to consider *all* instructions which take address as one of the operands.

Not necessarily. We ignore some uses in hasAddressTaken() and that can leak to this place.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98884/new/

https://reviews.llvm.org/D98884



More information about the llvm-commits mailing list