[llvm-commits] [PATCH] LTO code generator options

[Devang Patel]

On Tue, Nov 24, 2009 at 4:39 PM, Viktor Kutuzov
<vkutuzov at accesssoftek.com> wrote:
> Hi Devang,
>
> What use cases you are thinking of?

Several.

1 - LTO. The libLTO accepting command line options approach requires
linker to accept this command line options. The may require a) linker
change and b) build system changes to supply additional linker options
while using LTO. These goes against ease of use, that is transparent
LTO use that does not require any changes other than adding -O4 or
-flto on compiler command line. If subtarget features are encoded in
bitcode files then LTO use does not require any linker changes.

2 - One of the big strength of llvm toolset is bitcode representation
that can be saved on a disk and later on used to generate code. If I
do

   $ llvm-gcc <blah> foo.c -o foo.bc -emit-llvm; $ llc foo.bc -o foo.s

then it should match

   $ llvm-gcc -S foo.c -o foo.s

If I have to add/introduce additional llc command line options then
bitcode users may be surprised, which may in turn cost resources and
may require extra work from user. Again, this can be a avoided if
subtarget features are encoded in bitcode file.

3 - It is quite reasonable for some to put two copies of a function,
one for SSE3 machines, one for non-SSE machines, in one bitcode file
and let code generator generate appropriate code for each functions so
that the user can select desired function at run time. At Apple, we
supported similar requirements for Altivec vs. non-Altivec code. This
can be achieved if subtarget features like SSE3 are encoded in bitcode
files.

4 - This was the one of the biggest driving point behind the current
function attribute (originally proposed as function notes, if you
search archive) infrastructure we have in llvm.

-
Devang