[LLVMdev] Size and performance figures for LLVM?

[Bill Wendling]

On Tue, May 13, 2008 at 2:24 AM, Joachim Durchholz <jo at durchholz.org> wrote:
>
> Am Dienstag, den 13.05.2008, 00:42 -0700 schrieb Bill Wendling:
>> Sorry to step into this in the middle of a thread, but what exactly is
>> LLVM's autoconf doing that "autoconf shouldn't do if properly set up"?
>
> 1) Variables like CC, CXX, CFLAGS don't work properly when submitted via
> the command line. The handling seems to be inconsistent, i.e. it seems
> that parts of the toolchain receive these flags, others don't.
> This is just a cosmetic problem, of course.

Is this specifying CC, CXX, and CFLAGS during the "configure" process
or during the "make" process? The Makefiles seem to be using them in a
fairly consistent manner, as far as I can see. Which parts of the
toolchain don't get the flags? Also, are we talking LLVM or LLVM-GCC?

> 2) The setting of --build should be the default for --host, and the
> value of --host should be the default for --target. The build machinery
> seems to take the defaults for --host and --target from elsewhere,
> specifying just --build or --host will cause amd64 assembly to be fed to
> an assembler running in i686 mode.

I don't have much of an explanation for this. I would suggest
specifying all three (build/host/target) parameters if you're running
into this problem. It might help in the short term while we figure out
the issue.

> 3) On a 64-bit Ubuntu, setting --build/host/target=i686-pc-linux-gnu
> will work when compiling with gcc, but llvm-gcc will try to feed 64-bit
> machine code to the assembler in this situation. At least that's what
> happens when bootstrapping.

(We derive our configure script for llvm-gcc from gcc's configure
script, so there shouldn't be any drastic changes.) If you're
cross-compiling, I don't think you can do a bootstrap. If you're
compiling natively, you don't need to specify the build/host/target
flags.

Try disabling bootstrapping to see if this helps your problem.

> 4) I also dimly recall having seen llvm-gcc use 64-bit library paths for
> linking the 32-bit binaries (with ensuing hilarity, of course). I had
> postponed further investigation with this issue until after I'd get the
> assembly stage working - this approach had worked well with gcc, too.
>
> I'm under the impression that problems 1-3 are caused by autoconf as
> used in LLVM.
> I don't know about problem 4; it might be because Ubuntu's handling of
> library paths is inherently broken, or it might be a consequence of
> problem 3.
>
> If autoconf in LLVM can be cleaned up, I'd be really like to do it.
> Having expertise in that area might just be what's been missing, so if
> you're willing to give a helping hand to an autoconf newbie, this might
> finally work out.
>
I suggest looking at the autoconf/configure.ac (for LLVM) and
configure.in & gcc/configure.ac (for LLVM-GCC) scripts. You can find
documentation here:

  http://www.gnu.org/software/autoconf/manual/autoconf.html

The documentation will help you understand what the different macros
in the .ac/.in files are up to and how they work. I'll try to help as
much as I can, but I warn that I'm not an expert on GCC's configure
scripts (they do a lot of...interesting things there).

>> I have some experience with autoconf. I don't know if I've ever seen
>> one "properly set up" before. :-)
>
> I can understand that, it's a beast and few if any people ever set it up
> for cross compilation anyway.
> I assume that a cross compilation capable tool like LLVM needs a
> particularly careful setup in autoconf to avoid breakage like the above.
>

-bw