On Nov 10, 2007, at 6:43 PM, Chris Lattner wrote:
On Nov 10, 2007, at 1:59 AM, Christopher Lamb wrote:
I've been playing around with clang/LLVM looking at adding partial
support for the draft technical report for embedded C extensions
(TR18037, http://www.open-std.org/jtc1/sc22/wg14/www/docs/
n1169.pdf), in particular: memory spaces.
Nice!
It's been fairly simple to thread memory space ID's through LLVM
so far, but I'm new to FE's and the language from the TR has left
me wondering about the best way to implement this in clang. From
TR18037:
Clause 6.2.5 - Types, replace the second sentence of paragraph 25
with:
Each unqualified type has several qualified versions of its type,
38) corresponding to the combinations
of one, two, or all three of the const, volatile, and restrict
qualifiers, and all combinations
of any subset of these three qualifiers with one address space
qualifier. (Syntactically, an address
space qualifier is an address space name, so there is an address
space qualifier for each visible
address space name.)
The question I have is, how to track this info without adding
memory space id's to QualType, which seems
(1) infeasible given the implementation of QualType as a smart
pointer with only a few bits for additional data, and
(2) would loose the performance benefit of the current QualType
implementation (and thus the whole purpose of QualTypes existence,
it seems) if QualType were made extensible.
My first thought was to create a new Type subclass called
MemSpacedType that would essentially just be used to store the
memory space ID in addition to the QualType of the underlying
type. Is this the way to go? I'm deep in new territory and need
some seasoned advice.
Yep, I think this is a very reasonable way to go. QualType itself
is just an optimization for representing types. Instead of having
Type*'s everywhere, and having a "ConstType" type and
"RestrictType" type (that wrapped some other type), the information
is encoded into QualType.
However, this optimization for CVR qualifiers doesn't impact other
"qualifiers". It would be very reasonable to have an
AddressSpaceQualifiedType class, which takes an address space ID
and a QualType. This combines the space/time efficiency niceties
of QualType with the generality of having explicit classes for all
of these.
Good to hear. I had proceeded with this approach and have some simple
cases working (all the way through LLVM back end and generating
assembly, not bad for 2 evenings work!). I had to make some guesses
about all the functions that need to see "through" the ASQualType,
but I figured it would be mostly similar to other types that wrap
another type (Complex, Vector, etc.) with a few additions.
Also, address space qualifiers need to be parsed like other type CVR
qualifiers, rather than using an attribute, because attributes seem
to apply to the entire Decl irrespective of where in Decl the
attribute occurs (is this purposeful, or just the current state?).
_SpaceA int * foo;
is not
int * _SpaceA foo;
Also, the TR specifies that the names of address spaces are in the
type namespace. My question is, does that mean there also needs to
be an AddressSpaceType class?
The LLVM infrastructure supports a limited number of address spaces
(N) and I was planning on having built in support for qualifiers of
the form '_AddressSpace#' for all N. The TR says that a means to
define new address spaces may be provided by the compiler, and if
there are in-fact AddressSpaceType's would it be reasonable to think
that a typedef would be the correct means of binding a name to a
numbered AddressSpace?
allowing:
typedef _AddressSpace12 twelfth_space;
typedef _AddressSpace12 space_12;
also, this would allow the compiler to be "preloaded" with typedefs
for memory spaces based on the target, would it not?
--
Christopher Lamb
_______________________________________________
cfe-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
