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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Tom Stellard via llvm-dev
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


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [cfe-dev] Why Clang is yielding different LLVM IR return type for the same function

Tom Stellard via llvm-dev
> On Jul 2, 2018, at 11:48 PM, Zhang via cfe-dev <[hidden email]> 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.
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [cfe-dev] Why Clang is yielding different LLVM IR return type forthe same function

Tom Stellard via llvm-dev
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 ------------------
Date:  Tue, Jul 3, 2018 12:23 PM
To:  "Zhang"<[hidden email]>;
Cc:  "cfe-dev"<[hidden email]>; "llvm-dev"<[hidden email]>;
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 <[hidden email]> 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.

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] [cfe-dev] Why Clang is yielding different LLVM IR return type forthe same function

Tom Stellard via llvm-dev
On 7/2/2018 10:29 PM, Zhang via llvm-dev wrote:
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?
 

Run instcombine first.

-Eli
-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev