Jeff Cohen wrote:> OK, there may be some light at the end of the tunnel. I *can* force > an arbitrary .obj file to become part of the executable, one that is > not part of the executable's project. This is sufficient to eliminate > the global variable hack Morten introduced for the X86 target. > > But this still doesn't scale very well, as I'd have to manually > enumerate all .objs that are transforms and insert this list into > every project that builds an executable that needs them. > > But maybe if I got *very* clever... maybe too clever: I add a > post-build event to project Transforms that lists the .obj files that > now exist for the project and turn that into a response file that's > supplied to the exe link steps (if I can actually supply a response > file in VS...). And do it without requiring Perl or Python or > whatever that may not be available. Well, it's worth a try...The light was an oncoming train. Response files cannot be used within Visual Studio for a stupid technical reason that'd take some Microsoftie 30 minutes at most to fix if Microsoft bothered. Manually forcing each of the 73 object files in Transforms to link not only doesn't scale and would be a pain to maintain, but it doesn't work. The list is too long for VS to handle and it gets truncated, without warning, and in the middle of a file name, while creating the linker response file. So there's only two ways of dealing with this. The first is to use DLLs. To prevent code from being duplicated in multiple DLLs and the EXE, the bulk of the code in lib/ will have to go in DLLs. To keep the number of DLLs reasonable, many projects will have to be collapsed into one. There will be one DLL (and project) each for the transforms, the analyses, and the targets, and one catchall DLL for all common dependencies of the other three. The other way is to stick a unique global variable in each transform and analysis, create one header file that uses the globals in all the transforms, and likewise for the analyses, and include that header file from any executable that needs its services. There are few enough targets that using forced dependencies works, though this approach can be used here as well for consistency. It's a safe bet the LLVM community really dislikes the second approach. But there's no guarantee the first approach can actually be made to work. The only other option is to use makefiles to do builds and use VS only for debugging, something which would be really disliked by the Windows software development community.
Hello, I've been away working on other things so I have not been able to respond to mails on this mailing list for a while. But today I got back and I got the latest version of LLVM from CVS and built it successfully (after I deleted my old config.h which was included instead of the one in the new location)... Jeff Cohen wrote:> OK, there may be some light at the end of the tunnel. I *can* force > an arbitrary .obj file to become part of the executable, one that is > not part of the executable's project. This is sufficient to eliminate > the global variable hack Morten introduced for the X86 target.However I can no longer link it with our main project since the X86TargetMachine symbol is gone, and the intermediate object files are not available to the other project. I can't easily do the same as the fibonacci example does, so I have to put it back to the way it was.> But this still doesn't scale very well, as I'd have to manually > enumerate all .objs that are transforms and insert this list into > every project that builds an executable that needs them.I only have the problem with the X86TargetMachine because in the case of the optimization passes I explicitly call the createXXXPass functions. 'opt' creates passes by name instead and that's why it gets into trouble.> So there's only two ways of dealing with this. The first is to use > DLLs. To prevent code from being duplicated in multiple DLLs and the > EXE, the bulk of the code in lib/ will have to go in DLLs. To keep the > number of DLLs reasonable, many projects will have to be collapsed into > one. There will be one DLL (and project) each for the transforms, the > analyses, and the targets, and one catchall DLL for all common > dependencies of the other three.I looked at this, but the problem is that DLLs need explicit __declspec( dllimport) and __declspec(dllexport) on all symbols that are to be exported and imported. I think adding the declarators to all the symbols that are exported/imported is a lot of work and also pollutes the source for the Unix versions.> The other way is to stick a unique global variable in each transform and > analysis, create one header file that uses the globals in all the > transforms, and likewise for the analyses, and include that header file > from any executable that needs its services. There are few enough > targets that using forced dependencies works, though this approach can > be used here as well for consistency.I think this solution is quite OK considering almost all the modules already have such global symbols, namely the createXXXPass functions. m.
Morten Ofstad wrote:> Jeff Cohen wrote: > >> OK, there may be some light at the end of the tunnel. I *can* force >> an arbitrary .obj file to become part of the executable, one that is >> not part of the executable's project. This is sufficient to >> eliminate the global variable hack Morten introduced for the X86 target. > > > However I can no longer link it with our main project since the > X86TargetMachine symbol is gone, and the intermediate object files are > not available to the other project. I can't easily do the same as the > fibonacci example does, so I have to put it back to the way it was.Ouch... sorry about that.>> But this still doesn't scale very well, as I'd have to manually >> enumerate all .objs that are transforms and insert this list into >> every project that builds an executable that needs them. > > > I only have the problem with the X86TargetMachine because in the case > of the optimization passes I explicitly call the createXXXPass > functions. 'opt' creates passes by name instead and that's why it gets > into trouble. > >> So there's only two ways of dealing with this. The first is to use >> DLLs. To prevent code from being duplicated in multiple DLLs and the >> EXE, the bulk of the code in lib/ will have to go in DLLs. To keep >> the number of DLLs reasonable, many projects will have to be >> collapsed into one. There will be one DLL (and project) each for the >> transforms, the analyses, and the targets, and one catchall DLL for >> all common dependencies of the other three. > > > I looked at this, but the problem is that DLLs need explicit > __declspec( dllimport) and __declspec(dllexport) on all symbols that > are to be exported and imported. I think adding the declarators to all > the symbols that are exported/imported is a lot of work and also > pollutes the source for the Unix versions.Ouch again... you're right of course. The DLL approach won't work.>> The other way is to stick a unique global variable in each transform >> and analysis, create one header file that uses the globals in all the >> transforms, and likewise for the analyses, and include that header >> file from any executable that needs its services. There are few >> enough targets that using forced dependencies works, though this >> approach can be used here as well for consistency. > > > I think this solution is quite OK considering almost all the modules > already have such global symbols, namely the createXXXPass functions.That's a good point. The globals already exist (in the form of functions). The header files simply need dummy code to "use" them, and in such a way that the VC++ optimizer doesn't think it's dead code. A static constructor can do the job. Still need to include this header in every file with a main() function.> > m.
On Mon, 3 Jan 2005, Morten Ofstad wrote:> Hello,Welcome back,> I think this solution is quite OK considering almost all the modules already > have such global symbols, namely the createXXXPass functions.If you wanted to add a createXXX symbol for each pass that does not already have one, feel free to do so. -Chris -- http://nondot.org/sabre/ http://llvm.cs.uiuc.edu/