[LLVMdev] Inlining bitcast functions...

[Manish Gupta]

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>