[LLVMdev] [PATCH] print .weak directives
Chris Lattner
sabre at nondot.org
Sat Dec 9 11:29:51 PST 2006
On Sat, 9 Dec 2006, [UTF-8] Rafael Esp?ndola wrote:
> The attached patch makes the AsmPrinter emit one .weak directive for
> each weak global variable that is referenced at least once in a global
> table. It uses a std::set to print only one directive.
I'm sorry, I must be missing something here:
In order to have weak linkage (I'm ignoring external weak for the moment)
a global has to be defined in the LLVM code. Because it is defined in the
LLVM code, it will have to be printed out by the target asm printer
somewhere. When that happens, it will get a .weak directive emitted for
it.
External weak globals are different: since they are not defined in the .ll
file, it is not as simple to know whether or not to print them. There are
two ways to handle them:
1a. Whenever we have a use of the global, print out a .weak directive.
1b. Whenever we have a use of the global, add the global to a set and
print out .weak directives in doFinalization.
2. In doFinalization, scan all the globals and functions, emitting one
.weak directive for anything with external weak linkage, whether it is
used or not.
1a is suboptimal because extraneous .weak directives get emitted.
1b is what the asmprinter currently uses, but it misses uses from the
constant pool.
2 is potentially bad because it will emit a .weak directive even if a
global is not used. In practice, however, dead prototypes will have
been removed before asmprinting anyway, so this potential slight
inefficiency won't hurt anything.
You're proposing to add another set (to AsmPrinter) to keep track of
extern weak globals. This could cause .weak directives to potentially be
emitted twice (once in asmprinter once in armasmprinter, f.e.) and
requires the cost of maintaining the sets.
I think it would be simpler and more efficient in the common case to do
#2. What do you think? Am I missing something?
-Chris
--
http://nondot.org/sabre/
http://llvm.org/
More information about the llvm-dev
mailing list