On Dec 11, 2007, at 10:30 PM, Chris Lattner wrote:
How horrible would:
@foo = addrspace(1) external global i32
be?
I like that the order in the decl is the order in the type lots.
These now work with the rules being adjusted.
@foo = extern_weak global i32 addrspace(1)
@foo = external global i32 addrspace(1)
@foo = dllimport global i32 addrspace(1)
rather...
@foo = internal global i32 0 addrspace(1)
@foo = weak global i32 0 addrspace(1)
@foo = linkonce global i32 0 addrspace(1)
@foo = appending global i32 0 addrspace(1)
@foo = dllexport global i32 0 addrspace(1)
I prefer that too, but I don't see how you're going to get bison to
accept "external global i32 addrspace(1)".
The problem is placing the 'addrspace()' betwen the type name and the
value of a 'ConstVal'. The pattern for external linkage global
variables refers to 'Types' rather than 'ConstVal', so it works just
fine.
Please verify that the number of shift/reduce and reduce/reduce
conflicts doesn't go up.
They don't.
--
Christopher Lamb
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
