[llvm-commits] [llvm-gcc-4.2] r53572 - /llvm-gcc-4.2/trunk/gcc/llvm-convert.cpp

Duncan Sands baldrick at free.fr
Wed Jul 16 13:25:27 PDT 2008


Hi,

> > thanks for the explanation.  However llvm-gcc already supports
> > variable byte-offsets, i.e. where the value of the byte offset
> > depends on the value of some variable, the content of a memory
> > location etc.  Ada does this for example.  So why does ObjC2
> > need something special here?
> 
> Presumably the ObjC FE trees do not look like the Ada trees.

by the time they hit llvm-convert these aren't front-end trees
anymore.  I understand that there are many delicate issues when
mapping a language to gcc trees, but I'm still surprised that the
ObjC2 people felt it necessary to invent a new mechanism, rather
than exploiting the standard one (which has existed for many years,
and is mature).

> I don't know what the Ada trees look like.

You really don't want to know!  The funkiest ones are those
where the offset or size of a field of a struct nested inside
some other struct depends on the value of a field in the parent
struct.  In some situations you have to do hairy tricks for this,
which is what the mysterious PLACEHOLDER_EXPR exists for.  It
took a while to get this all working smoothly with llvm...

> In ObjC, the offset is actually there twice in the tree in effect ,  
> and the user
> needs to compensate at some stage.  Don't ask me why, I didn't write  
> it:)

Is this stuff (ObjC2) ever going to be pushed to mainline?

Duncan.



More information about the llvm-commits mailing list