llvm dev - Mar 2009 - [LLVMdev] setting up LLVM to *run on* amd64 but *generate code* for alpha

On Mon, Mar 16, 2009 at 11:25 AM, Chris Lattner <clattner at apple.com>
wrote:
> Hi Zack, welcome!
I regret to say I'm disappearing again.  I was only looking at LLVM
for a class project which is now done with, and I'm not really
interested in compiler development for the fun of it anymore.  I do
want to respond to some of the things that you (and others) said...
> On Mar 13, 2009, at 5:41 PM, Zack Weinberg wrote:
>> I'm trying to persuade llvm (svn trunk) to build in a mode where it
>> *runs on* amd64 but *generates code* for alpha, exclusively.
As a general note, if you're trying to do cross compilation work, it
is important to be able to set the compiler's *default* target
architecture.  "Oh, you can just build with support for all targets
and then stick -arch=foobar on the command line" is not good enough,
because setting up a cross compilation environment involves mucking
with a good half-dozen different programs and libraries, none of which
are configured in the same way -- oh, sure, you *can* hack up all
their build systems to pass an extra switch to the compiler, but you
really don't want to have to.
>> because Makefile.config has ARCH=Alpha, and Makefile.rules changes the
>> options passed to the build compiler based on ARCH.  IMO this is a
>> bug, but I don't understand your makefile system well enough to fix
>> it.
>
> LLVM and Clang (but not llvm-gcc) use a different approach than the
standard
> autoconf model for building cross tool chains.  Instead of configuring the
> build to specialize it for one target, we just set the list of enabled
> targets.  LLVM is natively cross build aware and the tools can all support
> multiple targets at once (even dynamically loading them).
>
> To pick a set of targets to build, configure llvm with the
> --enable-targets=foo option, where foo is "all" (the default)
"native" (host
> target only) or a list of llvm targets to build.  This is strictly an
> optimization to reduce build time of llvm, you should always be safe to
just
> build all targets.
I don't like this answer. ;-)

It is really really important for everything that has a "configure"
script to support the baseline set of options defined by Autoconf,
*with the semantics described in the Autoconf manual*.   It's nice
that LLVM can support more than one target per configuration, but that
doesn't excuse not making --target do something sensible.  (Per what I
said above, how about having --target just set the default target, and
if you want to prune the list there's still --enable-targets?)

What --target presently does just makes no sense at all.

I'd also like to mention that, on a one-year-old IBM laptop, building
all the LLVM back-ends takes about three times as long as just
building one of them.

-- I don't mean to be ragging on y'all, but the fact is that I gave up
on LLVM and went back to GCC for my project because of these build
problems.  I don't know if it would have been easier to make the
modifications to LLVM that I had in mind than the modifications I
ended up making to GCC -- but I didn't waste nearly a week trying to
get a working cross toolchain with GCC.

zw

On Mar 20, 2009, at 5:22 PM, Zack Weinberg wrote:
> On Mon, Mar 16, 2009 at 11:25 AM, Chris Lattner <clattner at
apple.com>
> wrote:
>> Hi Zack, welcome!
> I regret to say I'm disappearing again.  I was only looking at LLVM
> for a class project which is now done with, and I'm not really
> interested in compiler development for the fun of it anymore.  I do
> want to respond to some of the things that you (and others) said...
Sure, feedback is always welcome.
>>> To pick a set of targets to build, configure llvm with the
>> --enable-targets=foo option, where foo is "all" (the default)
>> "native" (host
>> target only) or a list of llvm targets to build.  This is strictly an
>> optimization to reduce build time of llvm, you should always be  
>> safe to just
>> build all targets.
>
> I don't like this answer. ;-)
I think that there are several reasons for this.  At the end of the  
day, this is a volunteer project driven by the interests of the  
community members.  Since no one has yet been interested in making  
what you needed happen, it doesn't work smoothly yet.  This is  
unfortunate but unlikely to get better until someone makes it happen.
> It is really really important for everything that has a
"configure"
> script to support the baseline set of options defined by Autoconf,
> *with the semantics described in the Autoconf manual*.
Sure, we have that.  If you were asking about llvm-gcc, I could have  
explained how to do that very simply.  You were asking about LLVM (a  
generic framework for building compilers out of) and clang (which is  
not fully mature and doesn't have this sort of thing yet) so you got  
the "current answer".
> It's nice
> that LLVM can support more than one target per configuration, but that
> doesn't excuse not making --target do something sensible.  (Per what I
> said above, how about having --target just set the default target, and
> if you want to prune the list there's still --enable-targets?)
>
> What --target presently does just makes no sense at all.
Agreed, it would be nice for someone to fix that if there cared  
enough :).
> I'd also like to mention that, on a one-year-old IBM laptop, building
> all the LLVM back-ends takes about three times as long as just
> building one of them.
That's exactly why we have --enable-targets.
> -- I don't mean to be ragging on y'all, but the fact is that I gave
up
> on LLVM and went back to GCC for my project because of these build
> problems.  I don't know if it would have been easier to make the
> modifications to LLVM that I had in mind than the modifications I
> ended up making to GCC -- but I didn't waste nearly a week trying to
> get a working cross toolchain with GCC.
It's unfortunate to hear that, but it sounds like you made the right  
choice.  If you are uninterested in investing in solving the problems  
you hit and would not derive any benefit from the capabilities that  
LLVM provides, then using GCC is an extremely reasonable thing to do.

-Chris

On Fri, Mar 20, 2009 at 10:28 PM, Chris Lattner <clattner at apple.com>
wrote:
>> It is really really important for everything that has a
"configure"
>> script to support the baseline set of options defined by Autoconf,
>> *with the semantics described in the Autoconf manual*.
>
> Sure, we have that.  If you were asking about llvm-gcc, I could have
> explained how to do that very simply.  You were asking about LLVM (a
generic
> framework for building compilers out of) and clang (which is not fully
> mature and doesn't have this sort of thing yet) so you got the
"current
> answer".
This then may be a documentation problem more than anything else; the
website gave the impression that it wasn't actually necessary to build
llvm-gcc, just download the binaries and put them next to a build of
llvm core.  Also, it was not clear to me which of llvm-gcc and clang
was a more appropriate choice for the kind of project I was doing, so
I picked the "native" one... perhaps that was the real mistake.

zw

Le 21 mars 09 à 01:22, Zack Weinberg a écrit :
> On Mon, Mar 16, 2009 at 11:25 AM, Chris Lattner <clattner at
apple.com>
> wrote:
>> Hi Zack, welcome!
>
> I regret to say I'm disappearing again.  I was only looking at LLVM
> for a class project which is now done with, and I'm not really
> interested in compiler development for the fun of it anymore.  I do
> want to respond to some of the things that you (and others) said...
>
>> On Mar 13, 2009, at 5:41 PM, Zack Weinberg wrote:
>>> I'm trying to persuade llvm (svn trunk) to build in a mode
where it
>>> *runs on* amd64 but *generates code* for alpha, exclusively.
>
> As a general note, if you're trying to do cross compilation work, it
> is important to be able to set the compiler's *default* target
> architecture.  "Oh, you can just build with support for all targets
> and then stick -arch=foobar on the command line" is not good enough,
> because setting up a cross compilation environment involves mucking
> with a good half-dozen different programs and libraries, none of which
> are configured in the same way -- oh, sure, you *can* hack up all
> their build systems to pass an extra switch to the compiler, but you
> really don't want to have to.
I'm use to build library using the Apple gcc cross compiler (which  
works exactly like that, you have to pass arch for everything) and  
it's not a major issue:

./configure CC="gcc -arch pcc" CXX="g++ -arch pcc"

On Sat, Mar 21, 2009 at 2:57 AM, Jean-Daniel Dupas
<devlists at shadowlab.org> wrote:
> I'm use to build library using the Apple gcc cross compiler (which
> works exactly like that, you have to pass arch for everything) and
> it's not a major issue:
>
> ./configure CC="gcc -arch pcc" CXX="g++ -arch pcc"
That works great with anything that uses autoconf-style ./configure,
but that is by no means everything.

zw