[LLVMdev] Building bitcode modules
John Criswell
criswell at illinois.edu
Thu Sep 29 11:12:13 PDT 2011
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. 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).
Moving the feature to test-suite doesn't fix anything. 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 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.
-- John T.
More information about the llvm-dev
mailing list