[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 

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?



More information about the llvm-dev mailing list