Arm port

Project Infrastructure LLVM Dev List Archives
1

Hi,

- Cortex-A8 needs a specific instruction scheduler as dual issue forces you to interleave some instructions to allow to run two instructions in the same cycle for the best performance (Cortex-A9 is out-of-order so dual issue is not an issue (!) for performance).
- Cortex-A8/A9 have several useful new instructions : for instance, bit operations like bitfield insertion/extraction or having a pair of instruction MOVW,MOVT to read a 32-bitconstant/address into only 2 instruction instead of 3 or 4, etc.
- VFPv3 is supported for backward compatibility but they are very slow and not pipelined.
- NEON (SIMD coprocessor) can do a lot of impressive operations on 32-bit float or integer of any size. Most VFP operations can be done through NEON for better performance.

Considering GCC can produce ARMv7, LLVM is not a good candidate as long as the latter has no support ARMv7.

The main advantage about LLVM is for its ability to produce in run-time a native code unlike GCC. But the result would be very suboptimal for some goals.

2

Christophe Avoinne wrote:

Hi,

- Cortex-A8 needs a specific instruction scheduler as dual issue forces
you to interleave some instructions to allow to run two instructions in
the same cycle for the best performance (Cortex-A9 is out-of-order so
dual issue is not an issue (!) for performance).
- Cortex-A8/A9 have several useful new instructions : for instance, bit
operations like bitfield insertion/extraction or having a pair of
instruction MOVW,MOVT to read a 32-bitconstant/address into only 2
instruction instead of 3 or 4, etc.
- VFPv3 is supported for backward compatibility but they are very slow
and not pipelined.
- NEON (SIMD coprocessor) can do a lot of impressive operations on
32-bit float or integer of any size. Most VFP operations can be done
through NEON for better performance.

Considering GCC can produce ARMv7, LLVM is not a good candidate as long
as the latter has no support ARMv7.

The main advantage about LLVM is for its ability to produce in run-time
a native code unlike GCC. But the result would be very suboptimal for
some goals.

Parts of this is replying to Christophe, part to Samuel, and part to Sandeep, I
decided that writing 3 different replies would have been too much like
pestering. Reply to any part you feel like, it all is about (ultimately) my
wanting to use the llvm to support moving FreeBSD to run on the OMAP3530 as
shown on the Pandora or maybe the BeagleBoard.

3

My goal is to have Cortex-A9 support complete in far less than three
months. I've recently gotten some additional help toward that goal, so
the pace should pick up soon.

As far as compiler texts, there are many newer texts to recommend as
just about all the major optimization passes are done differently
after SSA-form appeared in about 1991. However, for adding Cortex-A8
support, I don't think you'll need to know anything more than the old
Dragon book (Aho/Sethi/Ullman) has in it. Instruction selection is
done in LLVM using SelectionDAGs and the TableGen tool and it's
domain-specific language.

Start by looking at llvm/lib/Target/ARM/ARMInstrInfo.td and seeing how
the basic instructions are matched. For armv7/armv7a, a new file will
want to be created similar to how ARMInstrVFP.td is sequestered.

deep

4

Sandeep Patel wrote:

My goal is to have Cortex-A9 support complete in far less than three
months. I've recently gotten some additional help toward that goal, so
the pace should pick up soon.

As far as compiler texts, there are many newer texts to recommend as
just about all the major optimization passes are done differently
after SSA-form appeared in about 1991. However, for adding Cortex-A8
support, I don't think you'll need to know anything more than the old
Dragon book (Aho/Sethi/Ullman) has in it. Instruction selection is
done in LLVM using SelectionDAGs and the TableGen tool and it's
domain-specific language.

Start by looking at llvm/lib/Target/ARM/ARMInstrInfo.td and seeing how
the basic instructions are matched. For armv7/armv7a, a new file will
want to be created similar to how ARMInstrVFP.td is sequestered.

Just wanted to say, privately, I hugely appreciate this mail, I really want to
thank you! I'm going to see what kind of trouble I have working my way through
the Dragon book ... I know that, at school, it had a reputation of being able to
drive students completely crazy. I'm hoping that myu sheer interest is going to
make it a lot easier on me.

Knowing that I don't have to drop another hundred (or more) bucks on another
book is nice news. With luck, perhaps I can get myself into a state where I can
be of help to you. Do the FreeBSD folks (on the Arm project) know that the -A9
is probably going to get support in that time frame? If the -A9 is supported,
does that mean that the A8 support is subsumed in there? I *do* understand the
point you made about the multiple issue not having the problem of interfering
dependencies, but I'm not sure it means that A8 support would be included in A9
support.

For school once, I wrote a CPU emulator, and it had multiple issue. Hellacious
dependency checking problems.

5

no problem.

Note that the Dragon book, and most courses on compilers, focus on
parsing and semantic analysis and barely glaze over optimization, code
generation, instruction selection, etc. But in this case, the basic
concept of pattern matching DAGs against tables of instructions is
more or less what LLVM does.

deep

6

Sandeep Patel wrote:

My goal is to have Cortex-A9 support complete in far less than three
months. I've recently gotten some additional help toward that goal, so
the pace should pick up soon.

As far as compiler texts, there are many newer texts to recommend as
just about all the major optimization passes are done differently
after SSA-form appeared in about 1991. However, for adding Cortex-A8
support, I don't think you'll need to know anything more than the old
Dragon book (Aho/Sethi/Ullman) has in it. Instruction selection is
done in LLVM using SelectionDAGs and the TableGen tool and it's
domain-specific language.

Start by looking at llvm/lib/Target/ARM/ARMInstrInfo.td and seeing how
the basic instructions are matched. For armv7/armv7a, a new file will
want to be created similar to how ARMInstrVFP.td is sequestered.

OK, I've got enough to go on with, and I'm getting ready right now to begin
reading the dragon book, but one question bothers me regarding the present setup
of llvm: the use of the present Makefile tools (dmake & gmake). I was rather
surprised to find that a project that is bent toward supporting the BSD Unixes
doesn't have a set of BSD Makefiles. I'm not saying you have to toss away your
dmake/gmake files, you could keep them for those who feel more at ease in using
them, but shouldn't you have a set of BSD makefiles also? It happens that I
have experience using those makefiles, and adding in a set of Makefiles designed
to allow use of the BSD Make and the BSD Make template files (all those files in
/usr/share/mk on any *BSD system wouldn't be all that difficult to accomplish,
Would that be something you might wish to add?

7

Doesn't CMake support the BSD toolchain? The autotools dependencies of LLVM are slowly being replaced by the cross-platform CMake utility that will generate the makefiles or IDE build solutions for whatever toolchain you're using.

8

Samuel Crow wrote:

From: Chuck Robey <chuckr@telenix.org>
To: LLVM Developers Mailing List <llvmdev@cs.uiuc.edu>
Sent: Friday, May 22, 2009 9:22:53 AM
Subject: Re: [LLVMdev] Arm port

OK, I've got enough to go on with, and I'm getting ready right now to begin
reading the dragon book, but one question bothers me regarding the present setup
of llvm: the use of the present Makefile tools (dmake & gmake). I was rather
surprised to find that a project that is bent toward supporting the BSD Unixes
doesn't have a set of BSD Makefiles. I'm not saying you have to toss away your
dmake/gmake files, you could keep them for those who feel more at ease in using
them, but shouldn't you have a set of BSD makefiles also? It happens that I
have experience using those makefiles, and adding in a set of Makefiles designed
to allow use of the BSD Make and the BSD Make template files (all those files in
/usr/share/mk on any *BSD system wouldn't be all that difficult to accomplish,
Would that be something you might wish to add?

Doesn't CMake support the BSD toolchain? The autotools dependencies of LLVM are slowly being replaced by the cross-platform CMake utility that will generate the makefiles or IDE build solutions for whatever toolchain you're using.

The build I saw was using Cmake to drive Gmake, but let me get hold of the
latest release and see if that's still the way of things. Gmake makefiles will
generally not run in bsd make, and certainly no Gmake Makefile can make any use
whatever of the bsd.*.mk template makefiles that are commonly used in all bsd
builds.

But let me verify this, I'll get back to you.

9

Samuel Crow wrote:

From: Chuck Robey <chuckr@telenix.org>
To: LLVM Developers Mailing List <llvmdev@cs.uiuc.edu>
Sent: Friday, May 22, 2009 9:22:53 AM
Subject: Re: [LLVMdev] Arm port

OK, I've got enough to go on with, and I'm getting ready right now to begin
reading the dragon book, but one question bothers me regarding the present setup
of llvm: the use of the present Makefile tools (dmake & gmake). I was rather
surprised to find that a project that is bent toward supporting the BSD Unixes
doesn't have a set of BSD Makefiles. I'm not saying you have to toss away your
dmake/gmake files, you could keep them for those who feel more at ease in using
them, but shouldn't you have a set of BSD makefiles also? It happens that I
have experience using those makefiles, and adding in a set of Makefiles designed
to allow use of the BSD Make and the BSD Make template files (all those files in
/usr/share/mk on any *BSD system wouldn't be all that difficult to accomplish,
Would that be something you might wish to add?

Doesn't CMake support the BSD toolchain? The autotools dependencies of LLVM are slowly being replaced by the cross-platform CMake utility that will generate the makefiles or IDE build solutions for whatever toolchain you're using.

OK, I checked the llvm-2.5 Makefiles. They have constructs in them which cannot
be used in any BSD Makefile (such as the form of conditionals: ifndef is a GNU
Makeism), and won't run on any BSD Make. I know BSD Make and GNU Make well
enough, but I doon't know much about Cmake, I can say that all of the makefiles
I saw in llvm would (1) refuse to run on BSD make and (2) make no use whatever
of the large set of BSD Make template files that always reside in /usr/share/mk.

What I could offer, would be to capture a llvm build as done with the current
Makefile setup, and create a set of BSD Makefiles which would work with BSD
Makefiles and cooperate with the BSD template Makefiles (such as bsd.prog.mk,
bsd.lib.mk, etc). I think that the only thing that CMake is offering you is
that snazzy buildtime clock, but I think that's all. If you folks felt this
would be desireable. If llvm gets brought into any BSD, it's going to have to
be created by the BSD involved, anyhow ... well nearly all, I've seen recently
that OpenBSD seems to be making use of outside makefiles in outside sourced
things like Perl. But it would surely need BSD Makefiles for FreeBSD, and I'm
pretty sure for NetBSD also. They're not all that difficult to add in, I could
do that for you if you wanted.

10

Would that be something you might wish to add?

Patches are always welcome (c). Also somebody should continuously
maintain them otherwise they will become pretty useless soon.

11

Let me nix the idea. We don't want to go from 3 to 4 build systems... We're trying to cut the number down... If one wants, the right place to do this would be to ask the cmake people to generates BSD makefiles. Now, for distribution tar balls, we could consider bundling the cmake output for many flavors of build systems, for example, having a prebuilt and up-to-date Visual Studio project file, and Xcode project files, might well be nice.

12

Chuck Robey <chuckr@telenix.org> writes:

Doesn't CMake support the BSD toolchain?

OK, I checked the llvm-2.5 Makefiles. They have constructs in them
which cannot be used in any BSD Makefile (such as the form of
conditionals: ifndef is a GNU Makeism), and won't run on any BSD Make.
I know BSD Make and GNU Make well enough, but I doon't know much about
Cmake, I can say that all of the makefiles I saw in llvm would (1)
refuse to run on BSD make and (2) make no use whatever of the large
set of BSD Make template files that always reside in /usr/share/mk.

The makefiles distributed with LLVM have nothing to do with cmake.

Before devoting your time to implement yet-another-build-specification
for LLVM, it is worth checking that the makefiles generated by cmake are
indeed incompatible with BSD make. There are mixed reports on the 'Net.

This is a simple guide for using cmake with LLVM:

http://www.llvm.org/docs/CMake.html

What I could offer, would be to capture a llvm build as done with the current
Makefile setup,

The current LLVM makefile setup is far from trivial. Plus this would
generate yer another maintenance point.

and create a set of BSD Makefiles which would work with BSD
Makefiles and cooperate with the BSD template Makefiles (such as bsd.prog.mk,
bsd.lib.mk, etc). I think that the only thing that CMake is offering you is
that snazzy buildtime clock, but I think that's all.

Speaking as the original implementator of the LLVM cmake build spec, I
couldn't care less about the build time progress indicator. What cmake
provides is a single, fairly simple specification that covers lots of
platforms and build tools.

If you folks felt this would be desireable. If llvm gets brought into
any BSD, it's going to have to be created by the BSD involved, anyhow
... well nearly all, I've seen recently that OpenBSD seems to be
making use of outside makefiles in outside sourced things like Perl.
But it would surely need BSD Makefiles for FreeBSD, and I'm pretty
sure for NetBSD also. They're not all that difficult to add in, I
could do that for you if you wanted.

If incompatibilities of cmake and BSD make are found, maybe the cmake
people can fix them once is made clear that those issues are blocking
widespread usage on the BSD community. I can provide some help
addressing specific issues with the LLVM cmake specification (not with
cmake itself).

13

Hi, just chiming in here...

Óscar Fuentes wrote:

[...]

This is a simple guide for using cmake with LLVM:

http://www.llvm.org/docs/CMake.html
  
The makefiles distributed with LLVM have nothing to do with cmake.
From the few times I tried building LLVM with CMake I got the impression

that it wasn't completely mature yet (the "TODO" sections in the page
you mention above reinforce that impression). I remember at least one
other build error in the past, related to building a non-X86 backend.

With current svn I get:

%> mkdir llvm-svn-build
%> cd llvm-svn-build/
%> ccmake ../llvm-svn
# Basically only tweak the install prefix in ccmake, configure, generate
%> make
...
[ 2%] Built target LLVMSupport
[ 3%] Built target LLVMSystem
Linking CXX executable ../../bin/tblgen
../../lib/libLLVMSystem.a(Mutex.cpp.o): In function
`llvm::sys::Mutex::tryacquire()':
Mutex.cpp:(.text+0x3f): undefined reference to `pthread_mutex_trylock'
../../lib/libLLVMSystem.a(Mutex.cpp.o): In function
`llvm::sys::Mutex::Mutex(bool)':
Mutex.cpp:(.text+0x1bb): undefined reference to `pthread_mutexattr_init'
Mutex.cpp:(.text+0x216): undefined reference to `pthread_mutexattr_settype'
Mutex.cpp:(.text+0x256): undefined reference to
`pthread_mutexattr_setpshared'
Mutex.cpp:(.text+0x2a3): undefined reference to `pthread_mutexattr_destroy'
../../lib/libLLVMSystem.a(Mutex.cpp.o): In function
`llvm::sys::Mutex::Mutex(bool)':
Mutex.cpp:(.text+0x309): undefined reference to `pthread_mutexattr_init'
Mutex.cpp:(.text+0x364): undefined reference to `pthread_mutexattr_settype'
Mutex.cpp:(.text+0x3a4): undefined reference to
`pthread_mutexattr_setpshared'
Mutex.cpp:(.text+0x3f1): undefined reference to `pthread_mutexattr_destroy'
collect2: ld returned 1 exit status
make[2]: *** [bin/tblgen] Error 1
make[1]: *** [utils/TableGen/CMakeFiles/tblgen.dir/all] Error 2
make: *** [all] Error 2

This is on a Core2Duo 32-bit Gentoo Linux system, where building with
./configure; make succeeds without problems.

Best regards,
Paul

14

Óscar Fuentes wrote:

If you folks felt this would be desireable. If llvm gets brought into
any BSD, it's going to have to be created by the BSD involved, anyhow
... well nearly all, I've seen recently that OpenBSD seems to be
making use of outside makefiles in outside sourced things like Perl.
But it would surely need BSD Makefiles for FreeBSD, and I'm pretty
sure for NetBSD also. They're not all that difficult to add in, I
could do that for you if you wanted.

If incompatibilities of cmake and BSD make are found, maybe the cmake
people can fix them once is made clear that those issues are blocking
widespread usage on the BSD community. I can provide some help
addressing specific issues with the LLVM cmake specification (not with
cmake itself).

I never said it would block anything at all, and it won't. The BSD people will
easily add in their own Makefiles. I can never understand why so many people
find building Makefiles so terribly difficult, they seem simple enough to me.
What you've folks accomplished WRT to LLVM and CLANG, now that's impressive!
The Makefiles, sorry, that's kindergartener level stuff )(at least to me, and I
don't intend any sort of insult in anything you wrote). It's certainly, easily
possible to mrite truly complex Makefiles, but they don't need to be that way.
I find it rather trivial to go from a listing of a successful build to making
the makefile that drives it, a trivial task. If doing any of this is truly
complex in CMake, well, that seems to me to be a comment in itself ... it's not
in BSD Make.

Someone said that maybe CMake is already compatible with BSD make, so I quicly
went into one of your Makefiles and took out the first incompatibility I found.
Means ONLY that CMake != BSD Make, that's all. Looks to me to be a great deal
more like GNU Make, isn't that so?

I'm going to offer you the patches, and leave it up to you whatever you do with
it. I'll feel good about it, and if you decide that the best use is throw them
away, that's your decision, I'm not going to do anything past answer any
questions that occur. My own feeling is that adding in the ability to generate
BSD Makefiles from Cmake files is going to tremendously compllicate the ability
to fix build problems, things that would be simpler for folks on their
(whatever)BSD systems to just add in their own makefiles on their own systems.
BSD Make is going to make that easy enough to do, without even having to remove
whatever makefiles you place in there. It'd leave things far more easy to
troubleshoot. So, use it or don't, let's not argue the thing, ok?

15

Hi,

Paul Melis wrote:

Hi, just chiming in here...

Óscar Fuentes wrote:
  

[...]

This is a simple guide for using cmake with LLVM:

http://www.llvm.org/docs/CMake.html
  
The makefiles distributed with LLVM have nothing to do with cmake.
    

>From the few times I tried building LLVM with CMake I got the impression
that it wasn't completely mature yet (the "TODO" sections in the page
you mention above reinforce that impression). I remember at least one
other build error in the past, related to building a non-X86 backend.

With current svn I get:

%> mkdir llvm-svn-build
%> cd llvm-svn-build/
%> ccmake ../llvm-svn
# Basically only tweak the install prefix in ccmake, configure, generate
%> make
...
[ 2%] Built target LLVMSupport
[ 3%] Built target LLVMSystem
Linking CXX executable ../../bin/tblgen
../../lib/libLLVMSystem.a(Mutex.cpp.o): In function
`llvm::sys::Mutex::tryacquire()':
Mutex.cpp:(.text+0x3f): undefined reference to `pthread_mutex_trylock'
../../lib/libLLVMSystem.a(Mutex.cpp.o): In function
`llvm::sys::Mutex::Mutex(bool)':
Mutex.cpp:(.text+0x1bb): undefined reference to `pthread_mutexattr_init'
Mutex.cpp:(.text+0x216): undefined reference to `pthread_mutexattr_settype'
Mutex.cpp:(.text+0x256): undefined reference to
`pthread_mutexattr_setpshared'
Mutex.cpp:(.text+0x2a3): undefined reference to `pthread_mutexattr_destroy'
../../lib/libLLVMSystem.a(Mutex.cpp.o): In function
`llvm::sys::Mutex::Mutex(bool)':
Mutex.cpp:(.text+0x309): undefined reference to `pthread_mutexattr_init'
Mutex.cpp:(.text+0x364): undefined reference to `pthread_mutexattr_settype'
Mutex.cpp:(.text+0x3a4): undefined reference to
`pthread_mutexattr_setpshared'
Mutex.cpp:(.text+0x3f1): undefined reference to `pthread_mutexattr_destroy'
collect2: ld returned 1 exit status
make[2]: *** [bin/tblgen] Error 1
make[1]: *** [utils/TableGen/CMakeFiles/tblgen.dir/all] Error 2
make: *** [all] Error 2

This is on a Core2Duo 32-bit Gentoo Linux system, where building with
./configure; make succeeds without problems.
  

I see the cmake build scripts were quickly updated, builds fine now
with r72277 :slight_smile:

Paul

16

Paul Melis <llvm@assumetheposition.nl> writes:

Hi, just chiming in here...

Óscar Fuentes wrote:

[...]

This is a simple guide for using cmake with LLVM:

http://www.llvm.org/docs/CMake.html
  
The makefiles distributed with LLVM have nothing to do with cmake.
From the few times I tried building LLVM with CMake I got the impression

that it wasn't completely mature yet (the "TODO" sections in the page
you mention above reinforce that impression).

What's immature is the documentation, mostly because it tries to go
beyond what's really required. But on the other hand anyone who knows
how to use cmake shouldn't need the documentation, except perhaps for
the part that explains some variables specific to the LLVM build. (That
part is complete). A TODO on the web page doesn't mean that the feature
is missing. Cross compiling, for instance, should work (it worked when I
tried months ago) but it is not documented. You need to read the cmake
documentation for learning how to cross-compile.

Right now the only fundamental thing missing on the cmake build spec is
running the tests.

I remember at least one other build error in the past, related to
building a non-X86 backend.

With current svn I get:

[snip]

Mutex.cpp:(.text+0x3f): undefined reference to `pthread_mutex_trylock'
../../lib/libLLVMSystem.a(Mutex.cpp.o): In function
`llvm::sys::Mutex::Mutex(bool)':

[snip]

Thanks! Fixed.

BTW, bug reports are welcome.

17

Chuck Robey <chuckr@telenix.org> writes:

[snip]

Someone said that maybe CMake is already compatible with BSD make, so
I quicly went into one of your Makefiles and took out the first
incompatibility I found. Means ONLY that CMake != BSD Make, that's
all. Looks to me to be a great deal more like GNU Make, isn't that
so?

As said on my previous reply to you, the makefiles distributed with LLVM
are not related to CMake.

[snip]

My own feeling is that adding in the ability to generate BSD Makefiles
from Cmake files is going to tremendously compllicate the ability to
fix build problems,

Maybe there is a common misunderstanding here. CMake is not a build
tool, it is a build generator tool. That means that it competes with the
GNU autotools, for instance, but not with make, or gmake. CMake
generates makefiles (or project files for XCode, Visual Studio, etc) so
it actually requires some other tool (`make' in your case) for the
actual build. This is why I'm suggesting that you should check if CMake
generates makefiles compatible with BSD make, instead of writing (and
maintaining) them yourself. LLVM is a fast moving target: adding, moving
and removing source files and library requirements is common.

Ah, and as you may prefer to avoid the autotools, you need a
BSD-specific config.h file, don't you? In principle, CMake can provide
this too.

Please note that I'm just trying to avoid some possibly unnecesary work,
in the case that the current stuff we have does what you need.

[snip]

18

Mike Stump <mrs@apple.com> writes:

Would that be something you might wish to add?

Patches are always welcome (c).

Let me nix the idea. We don't want to go from 3 to 4 build
systems... We're trying to cut the number down... If one wants, the
right place to do this would be to ask the cmake people to generates
BSD makefiles. Now, for distribution tar balls, we could consider
bundling the cmake output for many flavors of build systems, for
example, having a prebuilt and up-to-date Visual Studio project file,
and Xcode project files, might well be nice.

Sadly, this is not possible in general. The files generated by CMake are
not guaranteed to be relocatable (they use absolute paths). That's the
reason why the old Visual Studio project files are still there: some
organization(s) using LLVM, for reasons unknown to me, require a
relocatable source tree and refuse to add CMake to their build setup.

19

Sadly, this is not possible in general.

To a hacker, few things are not possible. :slight_smile:

The files generated by CMake are not guaranteed to be relocatable (they use absolute paths).

A problem merely waiting for someone to fix it. If it is important, it will be fixed.

20

Build systems are a means to an end. The interesting stuff here is a
compiler. See <http://en.wikipedia.org/wiki/Bicycle_shed&gt;\.

If bending CMake to support BSD Make isn't in the cards, then I'd
suggest installing GNU Make and being done with it. It'll probably
work and I'd bet that the llvm-gcc autoconf manchinery probably
assumes gmake anyway, so you may well be stuck with it.

(FWIW, I find all of these build systems abhorrent in design and syntax.)

deep