llvm dev - May 2005 - [LLVMdev] Opaque Undef Types?

I'm looking at and running: 
test/Regression/Assembler/2005-05-05-OpaqueUndefValues.ll

which says:
; RUN: llvm-as < %s | llvm-dis | llvm-as

%t = type opaque
%x = global %t undef

Why is this valid? Shouldn't the assembler reject it (it doesn't)? How
can a global variable be defined as opaque? What's it size? 

Does this just indicate that %x is some "unknown undefined" global
which
will be resolved when linking?

If so, the CBE will choke (abort) on it, as does my XPLBE. Should I fix
this? How? Just declare it as a "char" or something? Won't that
confuse
the linker?

Reid
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20050513/f8522baf/attachment.sig>

On Fri, 13 May 2005, Reid Spencer wrote:
> I'm looking at and running:
> test/Regression/Assembler/2005-05-05-OpaqueUndefValues.ll
>
> which says:
> ; RUN: llvm-as < %s | llvm-dis | llvm-as
>
> %t = type opaque
> %x = global %t undef
>
> Why is this valid? Shouldn't the assembler reject it (it doesn't)?
How
> can a global variable be defined as opaque? What's it size?
It has no size yet.
> Does this just indicate that %x is some "unknown undefined"
global which
> will be resolved when linking?
undefined == external, so no.
> If so, the CBE will choke (abort) on it, as does my XPLBE. Should I fix
> this? How? Just declare it as a "char" or something? Won't
that confuse
> the linker?
The LLVM type system is more general than the C type system in a couple of 
ways.  For example, it also allows definitions like "{ opaque, int }".
This is fine as long as the type is resolved before codegen (e.g. at 
link-time), because code generators obviously like to have known offsets 
to elements in the struct.

Like you said, this sort of thing isn't supported by any of the other code 
generators, so I don't know why yours would be any different in this way.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/