[cfe-dev] [OpenCL patch] kernel attributes implementation

[Benyei, Guy]

Hi Doug,
I'm looking into the attributes stuff, and it seems like there was some effort to make it tablegenned all the way.
Currently even with the Attr.td file in place, each attribute must be added also in AttributeList.h, in AttributeList.cpp, and also there is specific handling for every attribute in SemaDeclAttr.cpp.

Is there any reason for this? 
I would imagine a simpler way to add attributes by only inserting them in the Attr.td file, and getting the rest for free.

Thanks
     Guy



-----Original Message-----
From: Douglas Gregor [mailto:dgregor at apple.com] 
Sent: Thursday, January 12, 2012 21:24
To: Benyei, Guy
Cc: Anton.Lokhmotov at arm.com; Tanya Lattner; cfe-dev at cs.uiuc.edu
Subject: Re: [OpenCL patch] kernel attributes implementation



Sent from my iPhone

On Jan 12, 2012, at 3:37 AM, "Benyei, Guy" <guy.benyei at intel.com> wrote:

> I can check this direction, but it will take time to finish this work.

Understood. 

> Anyhow, I think the short term solution with the OpaqueValueExpr instead DummyTypeExpr could be committed to solve this issue for now.

In the interest of rectifying more of the various vendors' OpenCL implementations, I can live with this in the short term. 

I feel obligated to make a code owner comment: Clang is great to work with specifically because we refactor until our new features can be dropped in beautifully. If we compromise on that approach too often, or for too long, our code base will be seriously damaged.

	- Doug


> Thanks
>   Guy
> 
> 
> 
> -----Original Message-----
> From: Anton Lokhmotov [mailto:Anton.Lokhmotov at arm.com] 
> Sent: Thursday, January 12, 2012 12:09
> To: 'Douglas Gregor'
> Cc: 'Tanya Lattner'; Benyei, Guy; cfe-dev at cs.uiuc.edu
> Subject: RE: [OpenCL patch] kernel attributes implementation
> 
>> DummyTypeExpr will encode the type as an expression to get it through
>> the AttributeList machinery without any refactoring. It will work, and
>> it is expedient, but it's not the right long-term solution for Clang.
>> If we have to go in this direction, we shouldn't introduce a new Expr
>> kind for it. Rather, we should just use OpaqueValueExpr, which can
>> fulfill the same role.
> 
> Agree.
> 
> Guy, is it something you could try to refactor?
> 
> Cheers,
> Anton.
> 
> 
> 
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.