[cfe-commits] patch: preserve address space

Mon Ping Wang wangmp at apple.com
Wed Jan 21 23:30:00 PST 2009


Hi Chris,

The spec seems to imply that "p1->arr" should be type [int3] which  
means that
    int* ptr = p1->arr;

is legal as the type are compatible though it is changing address  
spaces.

 From an implementation, it looks like today the LValue for the  
address has the correct address qualified type.  The Expression type  
for "p1->arr" would be have a different address space for its type.   
CodeGen should be aware of this and not generate a bit cast to change  
the address space between the two types and make sure that in the LLVM  
IR we generate, the address space is passed correctly in the types.

-- Mon Ping


On Jan 21, 2009, at 9:23 PM, Chris Lattner wrote:

>
> On Jan 21, 2009, at 8:14 PM, Mon Ping Wang wrote:
>
>> Hi,
>>
>> This patch fixes a case where we lose the address space when  
>> accessing a member of a structure.  For example,
>> consider
>>
>> typedef struct S {
>> int arr[ 3 ];
>> } S;
>>
>> __attribute__((address_space(1))) S* p1;
>> p1->arr[2] = 4;
>>
>> The address space associated with p1->arr should be address space 1.
>
> Hi Mon Ping,
>
> I am not sure that this is the right approach.  The embedded C spec  
> (which defines how address spaces work) says:
>
> "The effective type of an object for an access to its stored value  
> is the declared type of the object, if any, without any address- 
> space qualifier that the declared type may have.72)  If a value is  
> stored into
> an object having no declared type through an lvalue having a type  
> that is not a character type, then
> the type of the lvalue, without any address-space qualifier, becomes  
> the effective type of the object
> for that access and for subsequent accesses that do not modify the  
> stored value. "
>
> I think that this means that the type of "p1->arr" should be "int 
> [3]" in your example, not "int[3] __addrspace(1)".  In this case,  
> the code generator should generate the right address space  
> qualifiers from the l-value ("p1"), not from the expression type.
>
> This is similar to how volatile or const works.
>
> -Chris




More information about the cfe-commits mailing list