Quantcast

vector function return type

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

vector function return type

John Thompson
I'm looking at bug 5650 about using vector return types on functions, which is kind of difficult, not knowing all the ramifications of the type system.
 
For example, I need to change the return type of a function declaration, but there aren't any accessors for that.  Is that because it's complicated?
 
For example, since the QualType can apparently point to something, is that allocated storage, such that it would leak if I just assigned to it, or is the memory managed elsewhere?  Sorry, I probably should just study it some more.
 
Anyway, I've taken a stab at the bug fix, but I'm guessing it's not the right approach.  I added a couple of setters to FunctionDecl and FunctionType for the return type, not know if this is doable.  In the vector_size handler, I don't try to handle all the other types that need handling at this point, just wanting to get the vector return types to work as a first step.
 
-John

--
John Thompson
[hidden email]


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

vecreturn.patch (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: vector function return type

Eli Friedman
On Wed, Dec 2, 2009 at 6:34 PM, John Thompson
<[hidden email]> wrote:
> I'm looking at bug 5650 about using vector return types on functions, which
> is kind of difficult, not knowing all the ramifications of the type system.
>
> For example, I need to change the return type of a function declaration, but
> there aren't any accessors for that.  Is that because it's complicated?

It's not ridiculously complicated, but it's messy enough that you'll
want to write a helper method; something like the following should
work (not compiled, but should be approximately correct):
QualType NewResultTy; /* Your new result type */
QualType NewType;
if (const FunctionProtoType* FPT = FD->getType()-->getAs<FunctionProtoType>())
  NewType = Context.getFunctionType(NewResultTy,
FPT->arg_type_begin(), FPT->getNumArgs(), FPT->isVariadic(), 0,
FPT->hasExceptionSpec(), FPT->hasAnyxceptionSpec(),
FPT->getNumExceptions(), FPT->exception_begin(),
FPT->getNoReturnAttr());
else
  NewType = Context.getFunctionTypeNoProto(NewResultType,
FD->getType()->getAs<FunctionType>()->getNoReturnAttr());
FD->setType(NewType);

> Anyway, I've taken a stab at the bug fix, but I'm guessing it's not the
> right approach.  I added a couple of setters to FunctionDecl and
> FunctionType for the return type, not know if this is doable.  In the
> vector_size handler, I don't try to handle all the other types that need
> handling at this point, just wanting to get the vector return types to work
> as a first step.

You can't add a setter to FunctionType because the type system depends
on types being immutable.

-Eli

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: vector function return type

John McCall
In reply to this post by John Thompson

On Dec 2, 2009, at 6:34 PM, John Thompson wrote:

> I'm looking at bug 5650 about using vector return types on functions, which is kind of difficult, not knowing all the ramifications of the type system.
>  
> For example, I need to change the return type of a function declaration, but there aren't any accessors for that.  Is that because it's complicated?

Yes.  Among other problems, the redeclaration logic will be completely wrong if you take a fully-formed function declaration and change its type.  You really need to find the attribute before building the declaration, or at least before doing redeclaration checks on it.

Meta-question:  are we sure we want to allow this syntax?  Is this a gcc compatibility issue?  Because gcc's habit of pushing attributes from decls to random component types is already really bogus, and I'm hesitant to add to that when there's a perfectly reasonable solution (typedef the vector type) already.

> For example, since the QualType can apparently point to something, is that allocated storage, such that it would leak if I just assigned to it, or is the memory managed elsewhere?  Sorry, I probably should just study it some more.

Types are immutable;  the ASTContext uniques types based on their components, and then the type object lives forever as part of the ASTContext.  So you don't have to worry about leaking memory, but you also won't be able to naively modify types like this.

John.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: vector function return type

John Thompson
Thanks, it makes sense.  I'll see if I can put in support for handling this attribute as part of setting up the initial declaration.
 
Actually, what I really want is to implement Altivec vector support (i.e. the "vector" keyword and the associated built-in functions), but I figured fixing this was a useful stop along the way.
 
In a previous posting to this list about Altivec support, I was pointed to the vector_size attribute, and some gcc docs about __vector (it seems we don't have __vector yet), but I didn't really hear a yea or nay about putting in "vector" (and "__vector").  Our gcc-based PS3 compiler implements "vector" directly (i.e. no typedef or #define enabled in altivec.h).  I understand this will require a look-ahead to see if there is a numeric type following "vector".  Would it be okay for me to take a crack at doing this?
 
And looking father ahead, there are some areas where gcc diverges from the Altivec standard.  Would we want to fix this in Clang too?  (I.e. support both the gcc form and the standard, hopefully without requiring a new option?)
 
Thanks.
 
-John
On Wed, Dec 2, 2009 at 7:20 PM, John McCall <[hidden email]> wrote:

On Dec 2, 2009, at 6:34 PM, John Thompson wrote:

> I'm looking at bug 5650 about using vector return types on functions, which is kind of difficult, not knowing all the ramifications of the type system.
>
> For example, I need to change the return type of a function declaration, but there aren't any accessors for that.  Is that because it's complicated?

Yes.  Among other problems, the redeclaration logic will be completely wrong if you take a fully-formed function declaration and change its type.  You really need to find the attribute before building the declaration, or at least before doing redeclaration checks on it.

Meta-question:  are we sure we want to allow this syntax?  Is this a gcc compatibility issue?  Because gcc's habit of pushing attributes from decls to random component types is already really bogus, and I'm hesitant to add to that when there's a perfectly reasonable solution (typedef the vector type) already.

> For example, since the QualType can apparently point to something, is that allocated storage, such that it would leak if I just assigned to it, or is the memory managed elsewhere?  Sorry, I probably should just study it some more.

Types are immutable;  the ASTContext uniques types based on their components, and then the type object lives forever as part of the ASTContext.  So you don't have to worry about leaking memory, but you also won't be able to naively modify types like this.

John.



--
John Thompson
[hidden email]


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: vector function return type

John Thompson
Here's another go at it (fix for bug 5650).  It looks like the code was already in place for handling attributes for types before the declaration was finalized.  I basically just hacked up HandleVectorSizeAttr and moved it to be called from ProcessTypeAttributeList instead of ProcessDeclAttribute.
 
I also revised PrintVector in the type printer to put the vector_size attribute first, and revised the test in Sema/vector-init.c.
 
Is anything else needed for this?
-John
On Thu, Dec 3, 2009 at 7:24 AM, John Thompson <[hidden email]> wrote:
Thanks, it makes sense.  I'll see if I can put in support for handling this attribute as part of setting up the initial declaration.
 
Actually, what I really want is to implement Altivec vector support (i.e. the "vector" keyword and the associated built-in functions), but I figured fixing this was a useful stop along the way.
 
In a previous posting to this list about Altivec support, I was pointed to the vector_size attribute, and some gcc docs about __vector (it seems we don't have __vector yet), but I didn't really hear a yea or nay about putting in "vector" (and "__vector").  Our gcc-based PS3 compiler implements "vector" directly (i.e. no typedef or #define enabled in altivec.h).  I understand this will require a look-ahead to see if there is a numeric type following "vector".  Would it be okay for me to take a crack at doing this?
 
And looking father ahead, there are some areas where gcc diverges from the Altivec standard.  Would we want to fix this in Clang too?  (I.e. support both the gcc form and the standard, hopefully without requiring a new option?)
 
Thanks.
 
-John
On Wed, Dec 2, 2009 at 7:20 PM, John McCall <[hidden email]> wrote:

On Dec 2, 2009, at 6:34 PM, John Thompson wrote:

> I'm looking at bug 5650 about using vector return types on functions, which is kind of difficult, not knowing all the ramifications of the type system.
>
> For example, I need to change the return type of a function declaration, but there aren't any accessors for that.  Is that because it's complicated?

Yes.  Among other problems, the redeclaration logic will be completely wrong if you take a fully-formed function declaration and change its type.  You really need to find the attribute before building the declaration, or at least before doing redeclaration checks on it.

Meta-question:  are we sure we want to allow this syntax?  Is this a gcc compatibility issue?  Because gcc's habit of pushing attributes from decls to random component types is already really bogus, and I'm hesitant to add to that when there's a perfectly reasonable solution (typedef the vector type) already.

> For example, since the QualType can apparently point to something, is that allocated storage, such that it would leak if I just assigned to it, or is the memory managed elsewhere?  Sorry, I probably should just study it some more.

Types are immutable;  the ASTContext uniques types based on their components, and then the type object lives forever as part of the ASTContext.  So you don't have to worry about leaking memory, but you also won't be able to naively modify types like this.

John.



--
John Thompson
[hidden email]




--
John Thompson
[hidden email]


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

vecreturn1.patch (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: vector function return type

John McCall
On Dec 4, 2009, at 8:36 AM, John Thompson wrote:

> Here's another go at it (fix for bug 5650).  It looks like the code was already in place for handling attributes for types before the declaration was finalized.  I basically just hacked up HandleVectorSizeAttr and moved it to be called from ProcessTypeAttributeList instead of ProcessDeclAttribute.
>  
> I also revised PrintVector in the type printer to put the vector_size attribute first, and revised the test in Sema/vector-init.c.
>  
> Is anything else needed for this?


Looks good to me!  Feel free to commit whenever you're ready.

Please reference the PR number in the test case (and your commit message).

John.
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Loading...