On Jun 4, 2008, at 10:39 PM, Ian Lance Taylor wrote:
Devang Patel <[EMAIL PROTECTED]> writes:
If the optimizer can handle the symbol versioning case when one
definition with version is defined in the same source file as the
reference then you don't need new API.
For example,
a.o : refers to S and defines S at version V.
b.o : defines S.
Is inliner, at compile time allowed to inline uses of S in a.o using
the definition it has ?
The compiler doesn't know about symbol versions. The way they work is
that you give the symbol a name like S_V, and then use an assembly
level .symver directive to say that S_V is really S at version V. So
false inlining doesn't really arise in a single source file, unless
you do something rather odd.
If you plan to do link-time optimization, you need to be able to
capture all "assembler-level" features in your IR, somehow. Magic
that gets splatted out by the assembly printer will ideally be changed
to update the IR in some form.
LLVM LTO does exactly this. The front-end produces LLVM IR and does
no .s file printing at all. This IR goes through optimizations and at
-O3 and lower is then run through the code generator which produces
a .s file.
At -O4, the difference is that the code generator is not run, so LLVM
IR is written to disk. When LTO is run, we then load the LLVM IR for
all the LTO'able files and then run an LLVM Linker across them. This
does an LLVM IR level link step, which is aware of the semantics of
weak symbols, and many other details that come up when linking two
files together (however, it has no idea where those two files came
from, no idea about archive resolution, etc).
I don't know if LLVM properly supports symbol versions on ELF systems,
I would guess not yet. Since symbol versions affect linking, the LLVM
linker would have to have enough information to "do the right thing".
Once a fully linked LLVM IR file is produced, the total result is sent
through LLVM optimization passes, which then do interprocedural and
intraprocedural optimizations to continue improving the code. After
that, the normal LLVM code generator is run to produce a native form
of the LTO'd module and the system linker uses that to continue linking.
I don't know how closely your plans follow this model. If you think
this approach is reasonable, you really do need to reflect things like
symbol versions in your IR somehow. This compiler must know about
versions, and when it does, it is easy to avoid optimizations that are
invalid for them.
-Chris
