On Nov 13, 2007, at 10:59 PM, Chris Lattner wrote:
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.
Nice!
Also, address space qualifiers need to be parsed like other type
CVR qualifiers,
Right.
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?).
I don't recall off-hand. Steve is the guru of attributes, though
Nate may also know. It would certainly be nice to have these be
typedefs or #defines for __attribute__ syntax, just to avoid having
to tweak the parser for each device that needs address spaces.
I wholeheartedly agree. My first implementation used attributes, but
fails the test below. I looked at what it would take to get the
parser to understand otherwise and it seemed very non-trivial.
Especially because the number and name of keywords is target specific
it'd need something akin to attribute parsing, but just for
namespaces. Doesn't seem worth it.
_SpaceA int * foo;
is not
int * _SpaceA foo;
If attributes don't support this mechanism right now, I think we
should extend them to work with it. A specific attribute (e.g.
"address_space" in __attribute__((address_space(1)))) should be
markable as applying to the type instead of the decl.
Named address spaces were implemented using attributes successfully
by Codeplay in the VectorC compiler that I have experience with, so I
agree that it would be good to have this functionality.
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?
I haven't read the TR closely, but if it says this, it is very
strange :). I think this means that _SpaceA can't be either a
macro or a typedef. The issue is that it being a type means that
this should be legal (assuming _SpaceA is a valid space for the
current target:
_SpaceA int * foo;
void bar() {
typedef int _SpaceA;
_SpaceA y; // int y.
}
Is this really intended?
Here's the specific language. I misread it.
5.1.2 Address-space type qualifiers
Each address space other than the generic one has a unique name in
the form of an identifier.
Address space names are ordinary identifiers, sharing the same name
space as variables and
typedef names. Any such names follow the same rules for scope as
other ordinary identifiers (such
as typedef names). An implementation may provide an implementation-
defined set of intrinsic
address spaces that are, in effect, predefined at the start of every
translation unit. The names of
intrinsic address spaces must be reserved identifiers (beginning with
an underscore and an
uppercase letter or with two underscores). An implementation may
also optionally support a means
for new address space names to be defined within a translation unit.
I would strongly prefer some way for the various target-specific
memory spaces to be handled without having to hack the parser, I
don't know if this is possible though.
I prefer less parser hacking as well. I'm voting for being able to
apply attributes to types as well as the whole decl. =)
--
Christopher Lamb
_______________________________________________
cfe-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
