[LLVMdev] Building bitcode modules

[Eric Christopher]

On Sep 29, 2011, at 11:12 AM, John Criswell wrote:

> On 9/29/11 12:39 PM, Eric Christopher wrote:
>> On Sep 29, 2011, at 10:35 AM, John Criswell wrote:
>> 
>>> On 9/29/11 11:45 AM, Eric Christopher wrote:
>>>>> (I'm jumping into the middle of this conversation as it looks like you're discussing something that might be relevant to my work.  Sorry I'm not up to speed on the full context of the discussion...)
>>>>> 
>>>>> If you are asking whether anyone is using machinery in LLVM's build system to compile programs into LLVM bitcode files, the answer is yes.  The LLVM Makefile machinery is used not only by LLVM but by LLVM sub-projects like SAFECode, Automatic Pool Allocation, and others.  Practically every project I work on (either research or open-source) is organized as a sub-project of LLVM.
>>>>> 
>>>>> We compile our run-time libraries into LLVM bitcode files so that their functions can be inter-procedurally inlined and optimized by LLVM (either by llvm-ld or by libLTO).  This is simple to do as defining a macro in the Makefile turns this feature on (BYTECODE_LIBRARY=1, IIRC).
>>>>> 
>>>>> If you remove this feature, I will most likely have to re-implement it in all of our projects' Makefiles.  I may have to update our test suite Makefiles as well.  I'm not sure how time consuming that would be, but I'd rather not have to change all of my projects if I don't have to, even if the change is trivial.
>>>>> 
>>>>> If you have already removed this feature, can you please revert the commits and add it back?
>>>> It wouldn't be too bad. It was part of some larger commits, but I'll rework it a little cleaner and add in just the detection of a compiler that can emit bitcode.
>>> I'm not exactly sure what you're saying.  Are you saying that you will be maintaining this feature as it was in previous versions of LLVM, or are you saying that you're adding an alternate feature which will require that I adapt our Makefiles to use?
>> I'll be doing a) - there's no reason for you to need to update your makefiles. The current test-suite has the bits in it, I just moved it down to the test suite because nothing in the actual llvm tree depends on bit code being constructed.
> 
> I think you misunderstand.  

No, I didn't.

> The runtime libraries for my projects build a bitcode library (i.e., when I do a top-level "make" in my projects, bitcode libraries are built); they rely on LLVM's build system to do this.  If I have to change those Makefiles to use something like -emit-llvm or -O4, then not only will I spend my time updating the Makefiles that build my libraries, but I will also spend time updating the Makefiles that link in those libraries (because they'll no longer be suffixed with .bca).
> 

True, but that's not that bad IMO. It's how every other project that wants this sort of support works.

> Moving the feature to test-suite doesn't fix anything.

Well, it fixes the need for llvm to bother trying to figure out something that it doesn't need to know.

>  The LLVM build system is designed so that it can be easily reused by projects (a feature I implemented in the build system in the early days).  The test-suite build system is not quite so easily reused (or, at least, it's not designed to be, so I don't expect it to be).  I'd probably be better off adding custom build rules to my projects' Makefiles than trying to reuse test-suite Makefiles.
> 

I wasn't suggesting this, not even remotely.

> I can certainly make the changes, and I don't think it'll take too much of my time.  The question I have is why are you removing a feature that I and other people are using?  If removing the feature makes LLVM significantly easier to maintain or paves the way for a new feature in the build system, then the inconvenience I'll face is worth it.  On the other hand, if you're just removing the feature because you don't see a need for it, then from my perspective, I'm inconvenienced for nothing.

As far as I can tell you're one of the only people using it and none of the work is in the mainline llvm tree so by that definition it's an unused "feature" of the build system that wasn't necessary at the top level. llvm the library doesn't care about how to emit IR while being built. Subprojects may and the test-suite cared.

That said, I already said I was going to bring some level of support back so that the bitcode modules would continue to work. I don't see a reason for this feature, but also don't have any compelling reason to regress it on you.

-eric