llvm dev - Jul 2018 - Why Clang is yielding different LLVM IR return type for the same function

Hi:
So I have a library function called fooo() in a source file B.c and an external
A.c file that is referencing a function fooo() in it.
foo is returning a pointer to a structure


A.ll:
%struct._bar= type { %struct._foo, i32, i32 (%struct.doo*, %struct.doo*,
%struct.doo*)* }
declare i8* @fooo() #2


B.ll:
%struct._bar= type { %struct._foo, i32, i32 (%struct.doo*, %struct.doo*,
%struct.doo*)* }
define noalias %struct._bar* @fooo() #2{
   ..........
}





I am implementing a transform pass that operates on the merged version of A.ll
and B.ll , since they have different implementations llvm-link is inserting
extra bitcasts and thus various passes failed to operate, for example the
Inliner pass.
Is there anything else I could do to achieve what I need? Cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180703/f70af69b/attachment.html>

> On Jul 2, 2018, at 11:48 PM, Zhang via cfe-dev <cfe-dev at
lists.llvm.org> wrote:
> Hi:
> So I have a library function called fooo() in a source file B.c and an
external A.c file that is referencing a function fooo() in it.
> foo is returning a pointer to a structure
> 
> A.ll:
> %struct._bar= type { %struct._foo, i32, i32 (%struct.doo*, %struct.doo*,
%struct.doo*)* }
> declare i8* @fooo() #2
> 
> B.ll:
> %struct._bar= type { %struct._foo, i32, i32 (%struct.doo*, %struct.doo*,
%struct.doo*)* }
> define noalias %struct._bar* @fooo() #2{
>    ..........
> }
> 
> 
> I am implementing a transform pass that operates on the merged version of
A.ll and B.ll , since they have different implementations llvm-link is inserting
extra bitcasts and thus various passes failed to operate, for example the
Inliner pass.
> Is there anything else I could do to achieve what I need? Cheers
I wouldn't expect a bitcast to block inlining.  It's hard to say why
Clang is generating different code here.

John.

Hi John.
Thanks for the info. Currently I'm marking fooo() by hand by adding the
always_inline attribute then run the always inline pass using the following
code:


```
AnalysisManager<Module> AM;
AlwaysInlinerPass*
InlinerPass=cast<AlwaysInlinerPass>(createAlwaysInlinerLegacyPass());
InlinerPass->run(M,AM);
delete InlinerPass;

```
However the CallSites are not inlined. 
Reading lib/Transforms/IPO/AlwaysInliner.cpp , it says `` if
(CS.getCalledFunction() == &F)`` , since after linking the CallSites become
indirect calls with Bitcast ConstantExpr as target I think that's why the
inliner has no effect.
Any hints?

 
 
------------------ Original ------------------
From:  "John McCall"<rjmccall at apple.com>;
Date:  Tue, Jul 3, 2018 12:23 PM
To:  "Zhang"<admin at mayuyu.io>; 
Cc:  "cfe-dev"<cfe-dev at lists.llvm.org>;
"llvm-dev"<llvm-dev at lists.llvm.org>;
Subject:  Re: [cfe-dev] Why Clang is yielding different LLVM IR return type
forthe same function

 
> On Jul 2, 2018, at 11:48 PM, Zhang via cfe-dev <cfe-dev at
lists.llvm.org> wrote:
> Hi:
> So I have a library function called fooo() in a source file B.c and an
external A.c file that is referencing a function fooo() in it.
> foo is returning a pointer to a structure
> 
> A.ll:
> %struct._bar= type { %struct._foo, i32, i32 (%struct.doo*, %struct.doo*,
%struct.doo*)* }
> declare i8* @fooo() #2
> 
> B.ll:
> %struct._bar= type { %struct._foo, i32, i32 (%struct.doo*, %struct.doo*,
%struct.doo*)* }
> define noalias %struct._bar* @fooo() #2{
>    ..........
> }
> 
> 
> I am implementing a transform pass that operates on the merged version of
A.ll and B.ll , since they have different implementations llvm-link is inserting
extra bitcasts and thus various passes failed to operate, for example the
Inliner pass.
> Is there anything else I could do to achieve what I need? Cheers
I wouldn't expect a bitcast to block inlining.  It's hard to say why
Clang is generating different code here.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180703/ee07edc5/attachment.html>