search for: libvmcor

...> instead we only pass the address information to the linker (home made > linker) through some assembly directives. > What are you trying to do? Are you trying to change the logic of this > part or it is only simple refactoring? My short term goal is to make TargetAsmInfo not depend on libvmcore. This means that no methods in it should take GlobalValue*'s for example. There is a suite of GV classification methods that need to be moved somewhere else, probably in TargetLowering or asmprinter. One method in particular (SectionForGlobal) is virtual and only re- implemented for...

> My short term goal is to make TargetAsmInfo not depend on libvmcore. > This means that no methods in it should take GlobalValue*'s for > example. There is a suite of GV classification methods that need to > be moved somewhere else, probably in TargetLowering or asmprinter. One > method in particular (SectionForGlobal) is virtual and only...

...w the libraries are being used. Even if >you get past the linking problems, you will end up with re-registration >of passes and options, etc., which causes asserts. So, for now, there >aren't many good solutions. > > Is it possible to link opt and analyze with VMCore.o and use libVMcore.a with everything else? Also, do you know the PR# for the issue or the topics of any threads about it? I get the feeling I'm asking a lot of already asked questions. -- John T. >Reid. > >On Thu, 2006-06-22 at 17:21 -0500, John Criswell wrote: > > >>Has anything bee...

There are some bugs against it that state the current progress. The problem is that it depends on how the libraries are being used. Even if you get past the linking problems, you will end up with re-registration of passes and options, etc., which causes asserts. So, for now, there aren't many good solutions. Reid. On Thu, 2006-06-22 at 17:21 -0500, John Criswell wrote: > Has anything

...libLLVMCore.a instead of LLVMCore.o. Could someone at Apple and someone at UIUC please try this? I want to make sure that its not just my build environment that improves with the use of libLLVMCore.a Thanks, Reid. -------------- next part -------------- A non-text attachment was scrubbed... Name: libVMCore.patch Type: text/x-patch Size: 7091 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060531/40b3866d/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1...

(Sorry, previous post got sent by accident. This is the real one) Folks, Here's some timing results looking at LLVM when it uses libLLVMCore.o vs. libLLVMCore.a. We're trying to decide which way to go and thought some data would help. The net of it is that using libLLVMCore.a is cheaper in both time and size of executables. We save 37 seconds on linking LLVMCore and about 1 minute 30

Substituting the uses of a global with an absolute address would make all accesses to that global through pointer, which is very inefficient on PIC16. So we don't change the code generation for that global; instead we only pass the address information to the linker (home made linker) through some assembly directives. What are you trying to do? Are you trying to change the logic of this part or

Hi Sanjiv, The PIC16TargetAsmInfo::getBSSSectionForGlobal apparently does magic that reinterprets the "section" field of a global in a strange way: // If GV has a sectin name or section address create that section now. if (GV->hasSection()) { std::string SectName = GV->getSection(); // If address for a variable is specified, get the address and create