llvm dev - Oct 2008 - [LLVMdev] 2.4 Pre-release (v1) Available for Testing

OvermindDL1 <overminddl1 at gmail.com> writes:

[snip]
> On this first compile everything compiled except for llc and lli,
> which did not link due to:
>  unresolved external symbol "class llvm::FunctionPass * __cdecl
> llvm::createPBQPRegisterAllocator(void)"
That is because the lib/CodeGen project file is missing PBQP.cpp.

[snip]
> On Fri, Oct 10, 2008 at 2:11 PM, Tanya M. Lattner <tonic at
nondot.org> wrote:
>> Please COMPLETE ALL TESTING BY the end of the day on Oct. 19th!
> Speaking of, we really need a test suite to test llvm itself, and not
> llvm-gcc (to make sure llvm is correct on platforms without a gcc
> build system).  The closest we have is the Fibinocci project and that
> is anything but conclusive.
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?.

-- 
Oscar

Hi Oscar,

On 10-Oct-08, at 4:44 PM, Óscar Fuentes 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?.
Just to add one voice, we're going to be heavily using LLVM on Windows  
soon. I was very happy to see your CMake work since we were planning  
on doing something similar once we were going to be building on  
Windows regularly, and would really like a consistent build system  
across Linux/OS X/Windows.

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.

Stefanus

--
Stefanus Du Toit <stefanus.dutoit at rapidmind.com>
   RapidMind Inc.
   phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463

With respect to random testing LLVM pre-2.4 is doing extremely well, we 
have no unreported bugs right now.

John

Óscar Fuentes wrote:
> OvermindDL1 <overminddl1 at gmail.com> writes:
>
>   
>> On Fri, Oct 10, 2008 at 2:11 PM, Tanya M. Lattner <tonic at
nondot.org> wrote:
>>     
>>> Please COMPLETE ALL TESTING BY the end of the day on Oct. 19th!
>>>       
>> Speaking of, we really need a test suite to test llvm itself, and not
>> llvm-gcc (to make sure llvm is correct on platforms without a gcc
>> build system).  The closest we have is the Fibinocci project and that
>> is anything but conclusive.
>>     
>
> 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.
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 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?.
> 
> --
> Oscar
I, for one, hugely appreciate your effort and the CMake build files. My
primary target is the Windows platform, and I'd *LOVE* to see LLVM working
on windows. I think this is a "build it and they will come" argument,
but
LLVM is hugely useful for the kind of work I'm doing, and ATM I'm
resorting
to using LLVM on a *nix system while preparing (hoping?) for a win32 build
to work. The near nil penetration is a side effect of the lack of
availability IMO: How can I use it when it's not working in the first
place?..

I'd be willing to help test and, if I'm at a point where I actually know
what I'm doing ;), possibly contribute to make The Fully Working LLVM Win32
Build a reality.

- Sherief

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
On Behalf Of Sherief N. Farouk
Sent: Friday, October 10, 2008 3:52 PM
To: 'LLVM Developers Mailing List'
Subject: Re: [LLVMdev] 2.4 Pre-release (v1) Available for Testing
> 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?.
> 
> --
> Oscar
I, for one, hugely appreciate your effort and the CMake build files. My
primary target is the Windows platform, and I'd *LOVE* to see LLVM
working
on windows. I think this is a "build it and they will come" argument,
but
LLVM is hugely useful for the kind of work I'm doing, and ATM I'm
resorting
to using LLVM on a *nix system while preparing (hoping?) for a win32
build
to work. The near nil penetration is a side effect of the lack of
availability IMO: How can I use it when it's not working in the first
place?..

I'd be willing to help test and, if I'm at a point where I actually know
what I'm doing ;), possibly contribute to make The Fully Working LLVM
Win32
Build a reality.

- Sherief

I have a working VS2K5 solution/proj file that builds everything
correctly I could pass on if anyone is interested. 
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Stefanus Du Toit wrote:
 >>Just to add one voice, we're going to be heavily using LLVM on 
Windows soon

Add me to; I target/use Linux and Windows.

-srs

On Oct 10, 2008, at 1:44 PM, Óscar Fuentes wrote:
> OvermindDL1 <overminddl1 at gmail.com> writes:
>
> [snip]
>
>> On this first compile everything compiled except for llc and lli,
>> which did not link due to:
>> unresolved external symbol "class llvm::FunctionPass * __cdecl
>> llvm::createPBQPRegisterAllocator(void)"
>
> That is because the lib/CodeGen project file is missing PBQP.cpp.
Can someone on windows please submit a patch?

Thanks,

-Chris

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.