On Dec 11, 2007, at 10:12 PM, Christopher Lamb wrote:
On Dec 11, 2007, at 9:16 PM, Chris Lattner wrote:
On Dec 11, 2007, at 9:08 PM, Christopher Lamb wrote:
On Dec 11, 2007, at 8:50 PM, Chris Lattner wrote:
That is a very strong argument to me, but it seems to argue even
more
strongly for:
@G = constant float addrspace(5) 1.0, section "foo", align 4
Your example above would then be:
@foo = constant float addrspace(1)* addrspace(2) 1.0
which has type:
float addrspace(1)* addrspace(2)*
What do you think? the downside is that this may cause bison to
have
issues :)
This is ideally what I wanted, but it would mean seriously mucking
with bison and changing how all CosntVal's are handled. I can give
it a try.
Hrm, I think bison will get extremely grumpy about this.
I feared.
Quick question, what is the syntax for an external GV with an ASI?
Sticky wicket, that. It should be:
@foo = external global i32 addrspace(1)
But that's not working right now....
Right, because it would require the same parsing logic as the
proposal
above :).
I don't think so. I think the rules were simply missing the
OptAddrSpace.
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)
--
Christopher Lamb
_______________________________________________
llvm-commits mailing list
llvm-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
