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

[OvermindDL1]

On Fri, Oct 10, 2008 at 2:44 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> That is because the lib/CodeGen project file is missing PBQP.cpp.

That did not help, that cpp and its header do not contain
createPBQPRegisterAllocator anywhere in them.  it was still missing
those files in the project though.  What did fix it was adding in
RegAllocPBQP.cpp, so that file, and the PBQP.cpp/.h need to be added
to the VS project.


On Fri, Oct 10, 2008 at 2:44 PM, Óscar Fuentes <ofv at wanadoo.es> wrote:
> I could add that to my CMake build system TODO, but so far I'm a bit
> skeptic about LLVM relevance on the non-Unix world. The Windows build
> can be broken for a long period before anyone notices. The VS2003
> support is broken since a long time ago and, apart from myself, no other
> user cares. Seems that LLVM penetration on Windows, for instance, is
> almost nil. Is it really worth the trouble to support things like
> testing on systems that almost nobody (wants to) use?.

Well I use it, and I know of three other windows LLVM users that have
contacted me for help with their own projects as well.  The VC2k3
support is broken because of a "friend" declaration in LLVM in a way
that VS2k3 does not support (2k3's fault, although the friend usage
was also questionable...).

Although I think the main lack of visible Windows users (there are
definitely Windows llvm users) is because llvm feels so gcc oriented,
rather then being a truly open code generator (I mean come on, you try
to put in exception information even and it generates calls to the gcc
crt, it should *NOT* be doing that if it wants to be a truly platform
agnostic generator, and that is just one example among many).


On Fri, Oct 10, 2008 at 3:02 PM, Stefanus Du Toit
<stefanus.dutoit at rapidmind.com> wrote:
> Once we get there we'll be happy to pitch in with an effort like this.
> If you come up with something, we may be able to set up some nightly
> test machines in the short term for various versions of Windows and
> compilers. Email me privately if you're interested.

If someone created some multi-platform (aka, not relying on gcc)
tests, I could donate a nightly test on windows as well.  Perhaps if
such tests were setup it would be best to use a testing framework like
boost::test (or whatever it was called) to test all kinds of features
and such of llvm that would be compiled and ran as an executable on
whatever platform, all without relying on any compiler like gcc or
vc++ (the boost's version seems to work perfectly well everywhere, I
have used it a few times and have nothing but praise for it).  For
testing the tools like lli and so forth then another C/C++ project
with llvm could build an application that calls those and runs tests
on them by calling with various arguments and seeing the responses and
so forth (boost::filesystem makes hiding all the multi-platform junk
of that easy sans the actual calling of the executable, but that can
easily be controlled by a macro in small segments).  Technically you
would not even need to test those external llvm apps as everything can
be tested in the direct code path itself when testing everything else
internally (as those apps just call the internal things anyway).


On Fri, Oct 10, 2008 at 3:19 PM, Kenneth Boyd <zaimoni at zaimoni.com> wrote:
> LLVM will be mostly irrelevant on Windows as long as it doesn't have
> either a native-enough testing framework on Windows, or a build process
> that chokes on canonical Windows tools.  [Specifically, Perl.  I get the
> same errors with unpatched LLVM sources with both ActiveState, and
> built-from-tarball Perl 5.8.8 .  I'd guess the root problem is that
> canonical Windows builds of Perl use cmd rather than sh for the command
> shell.]
>> .... Is it really worth the trouble to support things like
>> testing on systems that almost nobody (wants to) use?.
>>
> Assuming that the absence of testing is a sufficient cause for not
> wanting to use LLVM on that system, and the system is otherwise worth
> supporting: yes.
>
> Kenneth

I still do not see why all the tests revolve around llvm-gcc.  They
are not really testing llvm, they are testing llvm-gcc.  We need a
good testing framework built in c++ itself, that can be built by the
same compiler that builds llvm itself, which can then be run to do all
the tests and return a result back, perhaps even with a network
library like boosts to submit results to the website, it can all be
done in c++ quite easily and would work everywhere just fine, and yet
people feel the need to write all this external stuff.  Yes, we need
the external stuff to test llvm-gcc, but on platforms where there is
no llvm-gcc there needs to be a testing framework to fully test llvm
itself, in all ways, but fully through its api, not something else
like llvm-gcc.


On Fri, Oct 10, 2008 at 8:14 PM, Chris Lattner <clattner at apple.com> wrote:
>> That is because the lib/CodeGen project file is missing PBQP.cpp.
>
> Can someone on windows please submit a patch?

That was not the only missing file (there were three missing).  I can
send you my project file if you so wish, just added the three files to
the codegen project file, nothing special (it is simple xml, you can
copy/paste three new entries in that file yourself actually).  If you
want my project file, or a diff to the 2.4pr then just ask.

Actually, here, just add this into the rather obvious area in belongs
in, does not matter where in the section, just stick it with the rest
of the file xml nodes in the CodeGen.vcproj file.  No clue if anything
else is missing, but it all builds fine with these:
These two go in the Name="Source Files" section, search for Name="Source Files"
			<File
				RelativePath="..\..\lib\CodeGen\PBQP.cpp"
				>
			</File>
			<File
				RelativePath="..\..\lib\CodeGen\RegAllocPBQP.cpp"
				>
			</File>
And this goes in the Name="Header Files" section as a child node,
again, just search for Name="Header Files"
			<File
				RelativePath="..\..\lib\CodeGen\PBQP.h"
				>
			</File>

Actually, here is a unified diff too (for the CodeGen.vcproj that
comes with the 2.4 pr1), as stated though, who knows if it is missing
other files, but right now with these it builds.  If anyone needs me
to test the windows build just yell out on the list and I'll sync the
source and do a build and return the results to the list.
@@ -425,6 +425,10 @@
 				>
 			</File>
 			<File
+				RelativePath="..\..\lib\CodeGen\PBQP.cpp"
+				>
+			</File>
+			<File
 				RelativePath="..\..\lib\CodeGen\PHIElimination.cpp"
 				>
 			</File>
@@ -453,6 +457,10 @@
 				>
 			</File>
 			<File
+				RelativePath="..\..\lib\CodeGen\RegAllocPBQP.cpp"
+				>
+			</File>
+			<File
 				RelativePath="..\..\lib\CodeGen\RegAllocSimple.cpp"
 				>
 			</File>
@@ -736,6 +744,10 @@
 			</File>
 			<File
 				RelativePath="..\..\include\llvm\CodeGen\Passes.h"
+				>
+			</File>
+			<File
+				RelativePath="..\..\lib\CodeGen\PBQP.h"
 				>
 			</File>
 			<File


And for note, if anyone wants a test platform like I mentioned above,
one based completely in C++, I would be willing to help build it.  Do
note, I really have no clue what should be tested inside llvm, I
barely use it myself (not too deep in my project yet, work is getting
the best of my time right now) so I know not exactly what to test, but
I can help setup the framework for the tests if anyone wants to help
with making the actually testing parts (or at least telling me what
needs to be tested so I could start making them).  And for note, I
like boost, so I would probably require that for the framework as I
would use a few pieces out of it, but I do not think that is a big
deal as any distro I know of comes with it, and all the Windows devs I
know already have it too (it is just too useful not to have), so I do
not see it as an unnecessary addon, we could even tear out the parts
we would use and include it with the tests as well so others would not
require having it already if really wanted, its license encourages
that.