[LLVMdev] Inlining bitcast functions...

[Manish Gupta]

never-mind. Just hit me already solved similar issue using Jhon's

Function* callee = dyn_cast<Function>(call->getCalledValue()->
stripPointerCasts());


On Tue, Aug 5, 2014 at 11:26 PM, Manish Gupta <manishg at cs.ucsd.edu> wrote:

> Any answer on this issue. I am not able to inline any function called
> using bitcast.
>
>
> On Fri, Nov 9, 2012 at 5:09 PM, Relph, Richard <Richard.Relph at amd.com>
> wrote:
>
>> Spoke too soon... running the inst combine pass does seem to resolve the
>> linker/inlining issue. But the resulting code fails to run correctly. I was
>> expecting the same result that I get when running with unstripped modules,
>> that is passing test runs. When it still failed, I guessed the failure mode
>> to be the same, but it isn't.
>>
>> Not sure WHAT to make of this...
>> ________________________________________
>> From: Eli Friedman [eli.friedman at gmail.com]
>> Sent: Friday, November 09, 2012 4:08 PM
>> To: Relph, Richard
>> Cc: LLVMdev at cs.uiuc.edu
>> Subject: Re: [LLVMdev] Inlining bitcast functions...
>>
>> On Fri, Nov 9, 2012 at 3:58 PM, Relph, Richard <Richard.Relph at amd.com>
>> wrote:
>> > Eli,
>> >     Thanks. I don't think it's a bug in the linker, really… it's
>> required to treat (stripped) opaque types as different, since it really has
>> no way to know if the caller and the callee really are referring to the
>> same thing… though it then seems to turn right around and do exactly that
>> by inserting the bitcast. ;-) (That does come from the linker.)
>> >     That the linker 'works differently' if the modules are not stripped
>> is arguably a 'bug', since even if the opaque types happen to have the same
>> name, they still may not be referring to the same type.
>> >     That said, I think what the linker is doing with unstripped modules
>> is reasonable… Using an opaque structure's name to "match" types is really
>> the only option. And they are, in fact, in this case, referring to the same
>> type.
>> >     I would go a bit further, though, and say that IF the linker is (as
>> it seems to be) using opaque structure names to match types, then the
>> "strip" pass ought to leave opaque structure names intact. In this
>> particular case, the names aren't useless… Or perhaps ALL (stripped) opaque
>> types should merely be smashed together to avoid the troublesome bitcast.
>>
>> The name isn't a fundamental property of an LLVM struct type; we
>> preserve it for readability, but not at the expense of correctness.
>>
>> I think the linker uses the names as a hint to merge struct types, but
>> it also should be taking the structure of globals and instructions
>> which use the struct type into account.
>>
>> >     I'll look in to instcombine, but if you've got any further words of
>> advice on how to use it, they would be greatly appreciated.
>>
>> It's a pass; you run it.
>>
>> -Eli
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140806/57e2dd29/attachment.html>