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.
OvermindDL1 wrote:> 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.The *.ll source tests should not revolve around llvm-gcc. The *.c and *.cpp tests are as problematic as claimed. There has been some noise about relocating the frontend tests elsewhere, but I have no idea when that will actually happen.> 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.I can see using C++ test drivers as part of LLVM testing, but they really are a different level of testing than the DejaGNU/expect framework tests. I would not be comfortable using just C++ test drivers, but think they would be useful in enforcing things like IEEE semantics for APFloat, that are not easily accessible from driver programs. I've thought about this myself (basically, what to do for platforms that don't have a reasonable native expect like MingW32), and there aren't that many good future-compatible choices when you actually need to examine both stdout and stderr, and can't assume POSIX. My initial prototyping work on this indicates that it's: * easy to check for success/failure exit codes (can do this in both windows batchfile and Bourne shell script) and report last failing test case * moderately easy to check for success/failure/assert exit codes and report all failing test cases (Bourne shell script, do not know how to do this in windows batchfile). (When using msvcrt assert, the exit code from an assert is 3 so it can be distinguished from a normal EXIT_FAILURE. I don't know how this works on other platforms.) * painful to check stderr/stdout. Cf. earlier flamey thread. Basically, the only future-compatible options other than DejaGNU/expect I can think of are POSIX (which will not port to MSVC and MingW32), shell scripting (skeptical about this actually working generally), and Tcl. If future-compatibilty wasn't a requirement, Python is another possibility. (Yes, I know shell scripting isn't windows-centric. If the alternate CMake build system stabilizes, having a CTest alternate test driver suite would make a lot of sense.)> 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. >LLVM testing would benefit from a directly API-exercising testsuite regardless of whether there is llvm-gcc. Kenneth
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).
On Oct 10, 2008, at 8:09 PM, OvermindDL1 wrote:> 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.Please send a diff or project file. I have no way of testing this, so I don't want to attempt to apply the patch manually, thanks! -Chris
On Sat, Oct 11, 2008 at 12:32 PM, Chris Lattner <clattner at apple.com> wrote:> Please send a diff or project file. I have no way of testing this, so > I don't want to attempt to apply the patch manually, thanks!Project file attached, just override the one in the win32/CodeGen/ directory. -------------- next part -------------- A non-text attachment was scrubbed... Name: CodeGen.vcproj Type: application/xml Size: 18499 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081011/ad3bf840/attachment.wsdl>
Apparently Analagous Threads
- [LLVMdev] 2.4 Pre-release (v1) Available for Testing
- [LLVMdev] 2.4 Pre-release (v1) Available for Testing
- [LLVMdev] 2.4 Pre-release (v1) Available for Testing
- [LLVMdev] 2.4 Pre-release (v1) Available for Testing
- [LLVMdev] 2.4 Pre-release (v1) Available for Testing