First and foremost, the two most significant changes I would like to make:
1) llvm/lib/VMCore/... -> llvm/lib/IR/...
I've discussed potential names for the VMCore (or LLVMCore) library
with lots of folks, and the best idea anyone has was Chris's initial
suggestion: IR. So I'd like to minimize the bikeshed discussions on
this one. ;]
Oh I missed the discussion. I prefer "Core." Yes, bikeshed.
I dislike 'Core' and all other overly generic names. Specifically, why
is Support not Core? Or vice versa? I would like a name that actually
represents the principle organizing component, and that component in
this case is the C++ APIs making up the IR of the compiler.
I agree. LLVM IR exists in a layer of a very big stack, including clang, lldb, compiler_rt, etc. it's a very *important* layer, but calling it "core" is just misleading and non-descriptive.
Part of my motivation of naming it "IR" is that it makes it really clear what should be in there. Also, the only stuff that would move to include/llvm/IR are the things related to IR: the other stuff should be left where they are for now, but eventually move. For example: passmanager to transforms(?), Intrinsics to targets, Intrinsics to targets, AutoUpgrade to transforms, and AddressingMode.h somewhere not there
There is one interesting question here: should we move
include/llvm/*.h to include/llvm/IR/*.h to match other libraries?
IMHO, we may keep include/llvm/*. They should be essential interfaces.
I dislike the inconsistency of the include tree and the lib tree. When
that inconsistency is just collapsing an entire directory to a single
file, it seems fine and even good when the names align. But this seems
somewhat less principled than that.
Essentially, consistency is a strong argument. I'm looking for strong
arguments for keeping them where they are to counter that.
Right. IR is central to the compiler backend, but clients of clang or higher level things (who do use a lot of stuff from llvm/* also, directly) don't necessarily use IR).
s/AsmParser/IRASM/ (to be distinguished against MCASM)
This is a really good one.
I would paint this bikeshed LLParser or IRParser. "Asm" has to go though.
Personally, I'd like to get llvm/IR and CodeGen->IRGen done, then discuss other movements in separate threads :). But yes, there is a lot of progress that could be made here.