[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