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