[cfe-dev] Implementing address space via custom C++11 attribute

[Patrik Eklöf via cfe-dev]

Thanks for the answer. I see what you mean. Unfortunately, clang does not like if I put the attribute between the type and the pointer:

 

int [[vms::ptr_32]] * HiIAmA32BitPtr{ (int*)0xFFFF'FFFF };

 

error: 'ptr_32' attribute cannot be applied to types

int [[vms::ptr_32]] * HiIAmA32BitPtr{ (int*)0xFFFF'FFFF };

 

The documentation is a little unclear on how to configure these attributes. I have:

 

def VmsPtr32: TypeAttr

{

                let Spellings = [CXX11<"vms", "ptr_32">];

                let Documentation = [Undocumented];

}

 

What should I be doing to get clang to accept this?

 

Regards,

Patrik Eklöf

 

 

From: metafoo at gmail.com [mailto:metafoo at gmail.com] On Behalf Of Richard Smith
Sent: 03 February 2017 16:37
To: Patrik EKlöf <patrik.eklof at vmssoftware.com>
Cc: Clang Dev <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] Implementing address space via custom C++11 attribute

 

On 3 February 2017 at 12:58, Patrik EKlöf via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org> > wrote:

Hello dear community,

 

I’ve been trying to implement a way to set address spaces using a custom C++11-style attribute, but I’ve been running into problems. The syntax I’m trying to use is:

 

[[vms::ptr_32]] int* HiIAmA32BitPtr{ (int*)0xFFFF'FFFF };

 

But apparently clang ignores those C++11-style attributes. Looking at the source, it’s because the attribute isn’t attached properly to the DeclSpec since…

 

DeclaratorChunk& DeclType = D.getTypeObject(chunkIndex);

 

…returns NULL. Not sure why, or what it is doing. The alternative way of doing it that I found is doing:

 

int* [[vms::ptr_32]] HiIAmA32BitPtr{ (int*)0xFFFF'FFFF };

 

This attribute is detected properly, but the type passed into processTypeAttrs is int* (apparently if using the __attribute((address_space)) syntax, it passes in regulator int), and attaching the address space to int* doesn’t seem to work as clang creates an llvm::type (lib/CodeGen/CodeGenTypes.cpp) using the address space of the pointee instead of the actual pointer type. That seems weird to me, but I don’t know what exactly address spaces are or how they work.

 

So I’m a little confused on how to approach this. I would like the first syntax to work if possible,

 

That would be a mistake. An attribute in that position applies to the variable HiIAmA32BitPtr itself, not to its type. You should also consider cases like:

 

  int **p;

 

What if you want p to be a 32-bit pointer to a 64-bit pointer to int, or vice versa?

 

but I’m not sure how one would go about implementing that without breaking anything. The second syntax seems to behave in a non-ideal way, by passing in int* instead of int. Not sure how one would go about fixing that, or if one should just make a hack to try to get the underlying type. I use address spaces since it seems like a good way to use mixed pointer sizes in the same translation unit.

 

Any ideas or thoughts?

 

It seems like what your attribute is really saying is that the 'int' lives in a 32-bit address space. So this could be written as:

 

int [[vms::ptr_32]] * HiIAmA32BitPtr{ (int*)0xFFFF'FFFF };

 

That is, HiIAmA32BitPtr is a pointer to an "int in some 32-bit address space".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170203/af9314a3/attachment.html>