On Mon, Mar 14, 2016 at 10:45 AM, Yaxun Liu via cfe-commits
<cfe-commits@lists.llvm.org> wrote:
> yaxunl added a comment.
>
> Thanks for your comments.
>
> It works like this, e.g.
>
> $ cat prog.ll
> declare i32 @foo()
>
> define void @use_foo() {
>
>   %a = call i32 @foo()
>   ret void
>
> }
>
> $ cat lib_common.ll
> define linkonce_odr i32 @foo() {
>
>   ret i32 1;
>
> }
>
> $ cat lib_opt.ll
> define linkonce_odr i32 @foo() {
>
>   ret i32 2;
>
> }
>
> $ llvm-link prog.ll lib_common.ll -override lib_opt.ll -S
> ; ModuleID = 'llvm-link'
>
> define void @use_foo() {
>
>   %a = call i32 @foo()
>   ret void
>
> }
>
> define linkonce_odr i32 @foo() {
>
>   ret i32 2
>
> }
>
> We can put all common functions in lib_common.ll, then only put a subset in 
> lib_opt.ll. Functions in lib_opt.ll will override functions in lib_common.ll. 
> For different GPUs we provide different lib_opt.ll. Each GPU may override 
> different subset of lib_common.ll.
>
> We use __attribute__((linkonce_odr_linkage)) by following the precedence of 
> __attribute__((internal_linkage)) which exposes the LLVM internal_linkage to 
> C/C++ programmers. We would like to accept suggestions for a better way to 
> expose the linkonce_odr linkage.

The above is not an appropriate use for linkonce_odr linkage, because
the different definitions do not have the same semantics. It sounds
like you just want a weak symbol, which you can already get with
__attribute__((weak)).
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to