I've gone about as far as I can in building executables with VC++. The problem with the remaining ones is that they rely on the static constructor trick to register various modules. This doesn't work with VC++ because without an explicit external reference to these modules they simply can't be linked in to an executable. This isn't a new problem, of course. Morten originally ran into this getting the X86 backend to link in, and solved it by introducing a global variable that could be used as the external reference. The problem is, this doesn't scale. There are few code generator targets, and fewer still that one would care to use on Windows. But there are dozens of optimizations and analyses. It's not practical or maintainable to give each one a global variable and then reference it from each affected executable. So I can (and have, actually) build "opt", but it's just a big waste of bytes as it has no optimizations available to it. And if I understand things correctly, it means that the JIT can't do any optimizations either. I'm not really sure how to deal with this. The best solution I can come up with is to put all of these modules into DLLs. When a DLL is loaded, all of its static constructors are executed, regardless of which modules are externally referenced. Nonetheless, there must be at least *one* external reference, or else the DLL wouldn't be loaded automatically in the first place. The DLL could be manually loaded, but that would be introducing Windows-specific code in places you probably don't want it. However, one global (or dummy function) for all optimizations or all code generator targets or all analyses is much better than one for each optimization or target or analysis. I think this will work, but it does represent a major change in how the VC++ build is conducted and I want to get feedback first, especially from Morten.
Jeff, There should be a way to do what we do with the Unix Makefiles and build re-linked object modules. That is, when we build an analysis or transform pass, we create two things: a .o file and a .a file. They contain the same code but the latter is searchable while the former is not. Can you not "pre-link" a bunch of .obj files together with VC++ to produce a new .obj file? And, when linking something like opt, will it not just put all .obj files that you specify into the executable? I think this is the best approach as it avoids some slowness in start up of the tool if the equivalent DLL approach was taken. Reid. On Sat, 2005-01-01 at 17:05, Jeff Cohen wrote:> I've gone about as far as I can in building executables with VC++. The > problem with the remaining ones is that they rely on the static > constructor trick to register various modules. This doesn't work with > VC++ because without an explicit external reference to these modules > they simply can't be linked in to an executable. > > This isn't a new problem, of course. Morten originally ran into this > getting the X86 backend to link in, and solved it by introducing a > global variable that could be used as the external reference. The > problem is, this doesn't scale. There are few code generator targets, > and fewer still that one would care to use on Windows. But there are > dozens of optimizations and analyses. It's not practical or > maintainable to give each one a global variable and then reference it > from each affected executable. > > So I can (and have, actually) build "opt", but it's just a big waste of > bytes as it has no optimizations available to it. And if I understand > things correctly, it means that the JIT can't do any optimizations either. > > I'm not really sure how to deal with this. The best solution I can come > up with is to put all of these modules into DLLs. When a DLL is loaded, > all of its static constructors are executed, regardless of which modules > are externally referenced. Nonetheless, there must be at least *one* > external reference, or else the DLL wouldn't be loaded automatically in > the first place. The DLL could be manually loaded, but that would be > introducing Windows-specific code in places you probably don't want it. > However, one global (or dummy function) for all optimizations or all > code generator targets or all analyses is much better than one for each > optimization or target or analysis. > > I think this will work, but it does represent a major change in how the > VC++ build is conducted and I want to get feedback first, especially > from Morten. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20050101/ed471eca/attachment.sig>
No, VC++ has no way to combine multiple .obj files into one. Nor is there any way to force the entire contents of a .lib file into an executable. Believe me, I looked for a way. Morten couldn't find one either. Even Microsoft's command line tools can't do it. Advantage: GNU. DLLs aren't that slow any more. Windows is so dependent on DLLs (the Win32 API itself is implemented as DLLs) that a lot of effort has gone into optimizing them. You wouldn't believe the number of DLLs that are present in a process for a program that doesn't have any DLLs of its own. I even found the VC++ 6.0 runtime DLL in LLVM processes, and I haven't a clue how *that* got loaded (must be used by some system-supplied DLL). Reid Spencer wrote:>Jeff, > >There should be a way to do what we do with the Unix Makefiles and build >re-linked object modules. That is, when we build an analysis or >transform pass, we create two things: a .o file and a .a file. They >contain the same code but the latter is searchable while the former is >not. > >Can you not "pre-link" a bunch of .obj files together with VC++ to >produce a new .obj file? And, when linking something like opt, will it >not just put all .obj files that you specify into the executable? I >think this is the best approach as it avoids some slowness in start up >of the tool if the equivalent DLL approach was taken. > >Reid. > >On Sat, 2005-01-01 at 17:05, Jeff Cohen wrote: > > >>I've gone about as far as I can in building executables with VC++. The >>problem with the remaining ones is that they rely on the static >>constructor trick to register various modules. This doesn't work with >>VC++ because without an explicit external reference to these modules >>they simply can't be linked in to an executable. >> >>This isn't a new problem, of course. Morten originally ran into this >>getting the X86 backend to link in, and solved it by introducing a >>global variable that could be used as the external reference. The >>problem is, this doesn't scale. There are few code generator targets, >>and fewer still that one would care to use on Windows. But there are >>dozens of optimizations and analyses. It's not practical or >>maintainable to give each one a global variable and then reference it >>from each affected executable. >> >>So I can (and have, actually) build "opt", but it's just a big waste of >>bytes as it has no optimizations available to it. And if I understand >>things correctly, it means that the JIT can't do any optimizations either. >> >>I'm not really sure how to deal with this. The best solution I can come >>up with is to put all of these modules into DLLs. When a DLL is loaded, >>all of its static constructors are executed, regardless of which modules >>are externally referenced. Nonetheless, there must be at least *one* >>external reference, or else the DLL wouldn't be loaded automatically in >>the first place. The DLL could be manually loaded, but that would be >>introducing Windows-specific code in places you probably don't want it. >>However, one global (or dummy function) for all optimizations or all >>code generator targets or all analyses is much better than one for each >>optimization or target or analysis. >> >>I think this will work, but it does represent a major change in how the >>VC++ build is conducted and I want to get feedback first, especially >>from Morten. >> >>_______________________________________________ >>LLVM Developers mailing list >>LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev >> >>