rjmccall added a comment.
Yes, you should just stick with your post-processing pass or something like it.
The design of linkonce_odr linkage is that such definitions will only be
emitted when they are actually used. Even with this attribute, a translation
unit that consists solely of:
__att
tstellarAMD added a comment.
Hi John,
The problem we are trying to solve here is linking a LLVM bitcode program
(OpenCL kernel in this specific case) with an LLVM bitcode library (OpenCL
builtin library) and having the resulting LLVM bitcode module contain only the
program code and the library
rjmccall added a comment.
You could also get this effect by somehow making the definitions linkonce_odr
when they're linked in from the library. Or you could simply use the classic
static-archive technique of putting each symbol in its own object file and
linking against the whole thing as a s
rjmccall added a comment.
Does your linker not supported dead-code stripping?
http://reviews.llvm.org/D18095
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
yaxunl added a comment.
Sorry my previous example may have caused some confusion.
Previously I said I wanted to override function definitions. However the only
reason we want to add this attribute is so that unused functions will be
dropped by the linker.
http://reviews.llvm.org/D18095
___
rjmccall added a comment.
You still don't actually want linkonce_odr linkage. You don't want the weak
definition to be inlined, so it can't be ODR, and you want to force it to be
emitted in your library, so it can't be linkonce. You just want weak linkage.
There's an existing attribute for t
yaxunl added a comment.
If __attribute__((linkonce_odr_linkage)) is not a proper name for explicitly
setting linkage, how about __attribute((linkage=linkonce_odr))? This can be
extended to other linkages too.
http://reviews.llvm.org/D18095
___
cfe
yaxunl updated the summary for this revision.
yaxunl removed rL LLVM as the repository for this revision.
yaxunl updated this revision to Diff 51297.
yaxunl added a comment.
Simplify description of this attribute in AttrDocs since it causes some
confusion.
http://reviews.llvm.org/D18095
Files:
yaxunl added a comment.
we can turn off inlining when we build lib_common.ll, then do optimization and
inlining after linking with lib_common.ll and lib_opt.ll. Even if linkonce_odr
allows inlining, it is still OK.
Repository:
rL LLVM
http://reviews.llvm.org/D18095
__
rjmccall added a comment.
Well, your overriding definitions will be strong definitions. The question is
whether you want to allow inning of the weak definitions, i.e. the
possibly-overridden ones, and there I would assume not.
Repository:
rL LLVM
http://reviews.llvm.org/D18095
_
yaxunl added a comment.
Yes we want the overriding functions to be allowed to be inlined.
Repository:
rL LLVM
http://reviews.llvm.org/D18095
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cf
rjmccall added a comment.
linkonce_odr would allow them to be dropped if unused by the library. In fact,
we don't normally emit IR for functions that are linkonce and not used.
Do you actually want code in lib_common to e.g. inline the common
implementation instead of calling the optimized one
yaxunl added a comment.
My last example is not proper. In real cases, the functions are overridden by
functions with the same name and semantics but optimized for speed.
Besides, we want unused library functions in lib_common.ll and lib_opt.ll to be
dropped, weak attribute does not achieve that
rjmccall added a comment.
Your use case violates the "ODR" restriction on linkonce_odr.
Do you maybe just want __attribute__((weak))?
Repository:
rL LLVM
http://reviews.llvm.org/D18095
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http
On Mon, Mar 14, 2016 at 10:45 AM, Yaxun Liu via cfe-commits
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
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() {
rjmccall added a comment.
Okay, first off, linkonce_odr is not an acceptable term to be introducing as an
attribute name. If we need this, we can find some way to describe it that
isn't a random internal compiler term.
More importantly, I don't understand how your problem is solved by linkonce
17 matches
Mail list logo
