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
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/20140805/ded4d1ed/attachment.html>
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>