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
Stefanus Du Toit
2008-Oct-10 21:02 UTC
[LLVMdev] 2.4 Pre-release (v1) Available for Testing
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
Sherief N. Farouk
2008-Oct-10 22:52 UTC
[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?. > > -- > OscarI, 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?. > > -- > OscarI, 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. > > KennethI 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.