vector function return type

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

vecreturn.patch (2.07 KB)

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

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.

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

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

vecreturn1.patch (9.22 KB)

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.