[LLVMdev] 2.4 Pre-release (v1) Available for Testing

OvermindDL1 overminddl1 at gmail.com
Sat Oct 11 02:06:33 PDT 2008

On Fri, Oct 10, 2008 at 10:27 PM, Kenneth Boyd <zaimoni at zaimoni.com> wrote:
> /* snip */

I think a pure C++ llvm test platform would work quite well
personally.  Not only could you test little parts of the API, but you
can also create IR in memory (or load the occasional file, but then
that would not test more of the things, which is kind of the purpose)
and either JIT it to test execution of compiled llvm code, as well as
being able to run various optimization passes in different orders of
different sets and still verify that the code works correctly.  With
such a C++ test platform you do not need to do anything with the
standard output/input as you can read everything directly, do not need
error codes, would just need to make sure everything works as
expected.  Such as create some IR for known complicated problems for
many of the passes and confirm that they always work and nothing
breaks, can even make some that fail now that some optimization pass
should optimize so that would help encourage it to be fixed so that,
that one test would pass.

I see no reason why any shell scripts, DejaGNU, etc... or anything
would be necessary.  If a compiler is capable of compiling llvm, then
it is certainly most capable of creating and handling the tests
through pure C++ as well, as such you would make the tests far more
distributable.  Because many of my programs need to work on both
Windows XP clients and my FreeBSD server, I tend to not handle
anything that will not work on both without too much extra crap, and
things like this have always worked perfectly.  C++ is extremely
capable, and running tests through it tend to execute faster, able to
test more things, can code the tests faster (there are wonderful
libraries that speed such things up, like boost), and it "Just Works"
everywhere.  Relying on posix for example, is just as bad and useless
for multiplatform work as is relying on something like MFC
(consequently, it is reasons like this that I also *HATE* the automake
tools as they create the most convoluted horrible to deal with build
scripts in existence, where-as cmake works wonderfully, and if you
really need to do special crap like automake things do, it is just as
easy to whip up a short C++ program, add its project to your build,
have it build and execute first before building the rest, all easy to
do, and very multiplatform).

I do find it humorous though in how so many people seem to rely on 50
little types of shell scripts spread across 50 different languages
when C++ can do it all, and with the right libraries can do it all in
just about the same short amount of code, all faster, all more
reliable, all easier to use, and by far more multiplatform (as well as
the fact you do not have to memorize 50 languages, especially horrors
like M4 and the makefiles and the other automake tools).

More information about the llvm-dev mailing list