Factor Dominators.cpp, Verifier.cpp and Pass* out of lib/LLVMCore

[llvmbot]

Bugzilla Link	794
Resolution	FIXED
Resolved on	Feb 22, 2010 12:44
Version	1.0
OS	All
Reporter	LLVM Bugzilla Contributor

Extended Description

Not every user of lib/VMCore wants to run the verifier or use Passes. While
these facilities are common, they are not intrinsically part of the LLVM IR. In
particular, nothing in rest of lib/LLVMCore uses the Dominators classes other
than the Verifier using ET-Forest. The Pass.cpp and PassManagerT.h are
standalone and its only users in lib/VMCore are Verifier.cpp and AsmWriter.cpp,
both of which are targeted for factoring out of lib/VMCore.

It is suggested that the following changes be made:

1. Move Pass.cpp and PassManagerT.h to a new library, lib/Pass
2. Split ET-Forest stuff out of Dominators.h and Dominators.cpp and into its own
   module ETForest.h and ETForest.cpp. Not sure where this should live but it is
   used by the Verifier pass so could go where Verifier.cpp lives or perhaps
   in lib/Analysis.
3. Move Dominators.cpp to lib/Analysis
4. Move Verifier.cpp to lib/Analysis

This is the third in a set of enhancements to reduce the size of lib/VMCore.

Thoughts, ideas?

Reid.

[lattner]

Hrm, okay, I guess. Where would they be moved? What sort of client doesn't need to (at least) run the
verifier? Anything that uses the asmparser needs the verifier. And anything producing llvm code
dynamically should use it too, at least in a checking build.

What scenario do you see this saving anything?

-Chris

[llvmbot]

The verifier is useful when developing a front end based on LLVM so that you can
catch bugs in construction of the LLVM IR. However, once the front end is
stable, the verifier shouldn't be needed. That is, you've independently verified
that all combinations of input to the front end will produce valid LLVM IR
constructs. This is important for HLVM where we're dynamic compilation is an
important factor and it needs to be both small and fast. Removing these items
will assist in that situation.

[lattner]

if you're dynamically compiling stuff you need the pass manager though, right?

Are you running no optimizations? If you're running anything at all, you'll need mem2reg, which requires
dominators...

-Chris

[llvmbot]

Running zero optimizations would be an option for a dynamically compiled
language. In situations where the time to get started, because the program is
small and short-lived, optimization is a lot of overhead. In other situations,
optimization will be warranted (e.g. long running server programs).

For mem2reg, I don't need it if my compiler generates SSA registers and PHI's
properly. Its a harder to write code generator but that's where llvm2cpp helps
:) Essentially I'm doing dominators in the front end and at a higher level (in
the AST).

However, in general, you're right, I will need the pass stuff.

From a purely code structing point of view (and the need to get VMCore down to a
size that it doesn't break linkers), I think these classes can be taken out of
VMCore. The fact that 99% of LLVM programs will include the library that
Pass/Dominators/ETForest/Verify live in is a separate issue. The main issue is
paring down LLVMCore's size.

For that matter, we could just put Verifier, Dominators, Pass, and AsmWriter
into a separate library, LLVMPreCore, and the change would be pretty simple. It
doesn't buy us anything but making VMCore smaller and the rare situation where
you have a code generator that really doesn't want any of that stuff.

Reid.

[lattner]

Comments:

Running zero optimizations would be an option for a dynamically compiled
language. In situations where the time to get started, because the program is
small and short-lived, optimization is a lot of overhead.

Those are exactly the situations you don't want to JIT at all, you'd rather use interpretation.

For mem2reg, I don't need it if my compiler generates SSA registers and PHI's
properly. Its a harder to write code generator but that's where llvm2cpp helps
:) Essentially I'm doing dominators in the front end and at a higher level (in
the AST).

You're planning on doing full dominator frontier construction? Why duplicate what LLVM already
provides?

However, in general, you're right, I will need the pass stuff.

You absolutely need the pass stuff (if not dominators/verifier) for the code generator.

(and the need to get VMCore down to a size that it doesn't break linkers),

The fact that the Alpha linker breaks on VMcore currently is a bug in the alpha linker. It just happens
that apparently noone in the binutils community apparently cares enough about alpha to fix it. As
such, reducing vmcore for this is a workaround at best (though it is obviously still useful for other
purposes) .

From a purely code structing point of view, I think these classes can be taken out of
VMCore. The fact that 99% of LLVM programs will include the library that
Pass/Dominators/ETForest/Verify live in is a separate issue. The main issue is
paring down LLVMCore's size.

Hrm. I agree that logical structure is important and that it doesn't need to be represented exactly in
physical structure.

For that matter, we could just put Verifier, Dominators, Pass, and AsmWriter
into a separate library, LLVMPreCore, and the change would be pretty simple. It
doesn't buy us anything but making VMCore smaller and the rare situation where
you have a code generator that really doesn't want any of that stuff.

LLVMPreCore is a horrible name :). One of my guiding principles for software engineering is that if you
can't come up with a good name for something, you don't understand it :).

To make forward progress here, why not switch vmcore to be an archive?

-Chris

[llvmbot]

I'll relent on the "I don't need the Pass stuff" issue. That discussion isn't
driving the need to simplify and restructure VMCore.

The Alpha Linker may be broken, but we need to provide the workaround because we
"support" that platform.

Hrm. I agree that logical structure is important and that it doesn't need
to be represented exactly in physical structure.

Yes, agreed.

LLVMPreCore is a horrible name :). One of my guiding principles for software
engineering is that if you can't come up with a good name for something, you
don't understand it :).

Or that you didn't take enough time to even think about it, which is the case
here :)

To make forward progress here, why not switch vmcore to be an archive?

No. The reason we build VMCore as a .o is to save time in linking all the
tools because all of them need all of VMCore. What we want to do is take out
the things that are not needed by every LLVM based program and put those
things in a library.

I suppose what we need to do is some testing on link times and see what comes
out faster. The archive is fast to build and it might be faster to link because
it only has to wade through a symbol table of public symbols not all symbols.

[lattner]

LLVMPreCore is a horrible name :). One of my guiding principles for software
engineering is that if you can't come up with a good name for something, you
don't understand it :).

Or that you didn't take enough time to even think about it, which is the case
here :)

Some respect please. I have thought about this issue. you are the one who came up with the name.

If you're worried about compile time, please prove that linking a .a file will be slower than linking the
two .o files you plan to split the library into. It really doesn't make sense to uglify the (already complex)
library structure out of concerns for link times that are not backed with real numbers.

-Chris

[llvmbot]

LLVMPreCore is a horrible name :). One of my guiding principles for
software engineering is that if you can't come up with a good name for
something, you don't understand it :).

Or that you didn't take enough time to even think about it, which is the
case here :)

Some respect please. I have thought about this issue. you are the one who
came up with the name.

I think you misunderstood my comment. I was using "you" as in plural. Perhaps I
should should have written "one" instead. I fully agree with the principal you
are portraying and I have thought much about the issue as well. All I was
saying is that I didn't take enough time in thinking about the name of the
library (which is quite obvious on the face of it).

If you're worried about compile time, please prove that linking a .a file
will be slower than linking the two .o files you plan to split the library
into. It really doesn't make sense to uglify the (already complex) library
structure out of concerns for link times that are not backed with real
numbers.

That's what I'm doing.

Reid.

[lattner]

Thanks for the clarification, and thanks for investigating! Many people would appreciate smaller tools
with less vmcore stuff in it! :)

-Chris

[lattner]

Does VMCore being an archive fix this PR?

-Chris

[llvmbot]

Yes, it does. If a program doesn't use Pass/Verifier/Dominator then it won't get
linked in because VMCore is now an archive.

Resolving this bug.