[llvm-commits] [llvm] r72700 - in /llvm/trunk/tools/lto: LTOModule.cpp LTOModule.h

[Nick Lewycky]

Duncan Sands wrote:
> Devang Patel wrote:
>> On Tue, Jun 2, 2009 at 12:04 PM, Duncan Sands <baldrick at free.fr> wrote:
>>>> >From the description, I think this is an issue of emulating some funny
>>>> linker hacks in LTO mode rather than an issue of actual linking.  So
>>>> whether two files are linked with llvm-link has no effect on the
>>>> issue.
>>> Isn't LTO supposed to be more or less equivalent to: link using
>>> llvm-link, optimize using opt, codegen using llc?
>> No. In LTO mode, the linker collects and shares information from
>> bitcode files as well as from non-bitcode object files.
>>
>> llvm-link+opt+llc path does not collect & share any info from non-bit
>> code file. Actually llvlm-link+opt+llc is essentially same as generate
>> bitcode+opt+llc in this regard.
> 
> But Nick's patch doesn't seem to have anything to do with non-bit
> code files...

I think I understand the constraints on the problem.

There's nothing wrong without this code in libLTO if all the inputs are 
.bc files*, and obviously this code doesn't matter if all the inputs to 
the real linker are .o files.

I think the trouble is that they want to mix old objC .o files with 
newer objC .bc files. Your earlier suggestion about just changing the 
frontend was on the right track except for one problem: it would 
constitute a change in the ABI. A .bc file emitted with the newer 
compiler wouldn't behave correctly when linked with a .o file from the 
older frontend.

Still, it seems to me that this code could be factored better. The whole 
analysis of the ConstantStruct etc., seems like they belong in an 
LLVM-aware part of the Apple linker (such a piece probably doesn't exist 
yet, which explains why it was added to libLTO instead) and the libLTO 
side should just be restricted to generic operations like 'addSymbol' or 
'undefineSymbol'.

Nick

* It's not clear to me why not. My guess is that the runtime library has 
been updated to not do the startup-time rewriting of the superclass 
pointer, and the nonsense of having "strange contortions to avoid real 
linker symbols" is moot when you're doing LTO anyways since those 
symbols will fall away from normal LTO optimization.