[llvm-commits] [llvm] r55973 - in /llvm/trunk: include/llvm/Target/TargetAsmInfo.h lib/CodeGen/AsmPrinter/AsmPrinter.cpp lib/Target/ARM/ARMTargetAsmInfo.cpp lib/Target/PowerPC/PPCTargetAsmInfo.cpp lib/Target/TargetAsmInfo.cpp lib/Target/X86/X86Ta

[Dale Johannesen]

On Sep 9, 2008, at 1:02 AMPDT, Anton Korobeynikov wrote:
> Hi, Dale
>
>> the magic 'l' prefix for symbols on Darwin which are
>> to be passed through the assembler, then removed at
>> linktime (previously all references to this had been
>> hidden in the ObjC FE code, oh well).
> Sorry for bothering you again, but changing semantics of llvm.used in
> such target- and language- specific way is a bit... uhm...
> questionable.

The underlying problem is that two different characteristics are  
involved:  "the compiler must not delete this symbol", and "the  
compiler must emit something special to affect assembly- or link- time  
behavior".   Currently both these key off llvm.used, which is not so  
good because they are not the same thing and do not always apply to  
the same symbols.  I have been patching the existing mechanism to make  
it work, but I could be persuaded that a new mechanism is better.

> I know, that objc fe is very fragile, but can't it be fixed in such
> way?

What way?

> Also, could you please show and example, when the change you
> introduced is needed?

@interface Foo
- (void) bar;
@end
@implementation Foo
- (void) bar {}
@end

(with -m64) The generated symbol L_OBJC_CLASS_NAME_0, and others, were  
marked no-dead-strip, when in fact it would be safe to remove them if  
everything that references them is removed.  I'm not sure this can  
actually cause a runtime problem, at least right now, but ObjC is  
still changing and the people working on it tell me it should not  
behave this way.

> If fe cannot be fixed, why don't leave generic code in place and just
> override it in asmprinters? I think you can introduce new hook inside
> DarwinTargetAssemblerInfo to control 'dead code stripping directive
> emission' and handle everything without need to introduce some
> objc-related things into generic TAI.
>
> Does this sound reasonable?

I don't mind moving the logic into Darwin-specific code.  (Although  
UsedDirective is already darwin-only.)