[LLVMdev] Re: a few llvm questions, not time-critical

[Chris Lattner]

> * what is happening at the bottom of Instruction.h where you have
> all the enums that encompass #defines and an #include?  how does that
> work?  is it just to keep all the definitions in one place?

Yes, it's just to keep definitions all in one place.  It's arguably a bad
design on my part, and I may change it in the future.  Originally the
instruction set for LLVM was changing periodically, and finding all
different places that depended on the properties of the instructions was
quite the pain.

What that stuff at the bottom does is to allow putting all of the
"instruction properties" into one file: include/llvm/Instruction.def.
Unfortunately it really confuses doxygen and human readers, so it's
probably a bad thing now that LLVM has settled down.

The end result of the C preprocessor nastiness is that there is an opcode
enum defined in the Instruction class, one for every instruction type:
Instruction::Add, Instruction::PHINode, Instruction::Call, etc...

> * a lot of times i see stuff like 'const Something * MyFunc( args ) const;'
> what does the second const mean?

The first const binds to the return value, saying that a pointer to
constant something is returned.  The second const binds to the object that
the method is invoked on itself.  Basically it says that this method may
be invoked on either a const, or non-const method.  For example, if the
second const above was not there, this would be illegal.

void MyClass::MyFunc() {}  // No const..
const MyClass *Foo = ... ; // Note that this is a constant object
Foo->MyFunc();             // Error!

The error is because you are invoking a "non-const" method on a const
object.  This is illegal because you are basically telling the C++
compiler that MyFunc might modify the current object (by assigning to an
instance variable, for example), and that's an illegal operation on a
constant object.

> * when there are two versions of something, one const and one not const --
> like, say, a const getOperand and a nonconst one, what's up?  i'm not sure
> what to do with the const one.  as you maybe can imagine, in my c code
> there are no consts -- caveat programmor i guess.

In general, don't worry about it.  They are just there because they have
different return types.  For example, getOperand(x) on a constant object
returns a constant pointer, but getOperand(x) on a non-const object
returns a non-const pointer.

-Chris

http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/