[cfe-dev] "__device_builtin__" attribute ignored by clang AST matcher

Aaron Ballman via cfe-dev cfe-dev at lists.llvm.org
Thu Jul 30 03:57:52 PDT 2020


On Wed, Jul 29, 2020 at 10:49 PM Oliver Zhang
<oliverthekitten2017 at gmail.com> wrote:
>
> Yeah it confuses me a lot to see that almost all cuda attributes, such as "__host__", "__global__", "__constant__", "__device_builtin_surface_type__" and "__device_builtin_texture_type__", are retained by the AST, but just not "__device_builtin__".

That attribute came into existence as an ignored attribute in Clang:
https://reviews.llvm.org/D11690 and it seems to have never been
updated with an implementation.

~Aaron


>
> On Thu, Jul 30, 2020 at 8:14 AM David Rector <davrecthreads at gmail.com> wrote:
>>
>>
>>
>> > On Jul 29, 2020, at 10:07 AM, Aaron Ballman via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>> >
>> > On Wed, Jul 29, 2020 at 8:47 AM Oliver Zhang via cfe-dev
>> > <cfe-dev at lists.llvm.org> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I'd like to use the clang AST matcher to match the "__device_builtin__" attribute (ie, "__attribute__((device_builtin))") in pre-processed cuda code, but it seems that the matcher just ignores the attribute. (In clang/Sema/AttrParsedAttrKinds.inc, "AttributeCommonInfo::IgnoredAttribute" is returned upon __device_builtin__.)
>> >>
>> >> Can anyone please provide any information on how to customize the matcher to match the ignored attribute?
>> >
>> > I suspect you cannot match against the ignored attribute because
>> > ignored attributes are not typically retained by the AST:
>> > https://godbolt.org/z/4v574o
>>
>> FWIW, I think it should be retained.  If we are already retaining loads of type sugar nodes, which like ignored attributes have no effect on semantics, why not just make it a policy to keep a representation of all written syntax in the AST?
>>
>> In fact, I would even go so far as to say macro expansions should be represented in the AST, or at least any with balanced delimiters — we could have Decl & Stmt & Expr "sugar" nodes akin to what a TypedefType is for Types.  But I grant that would be a bigger step.
>>
>> >
>> > Or are you finding that the AST has the attribute but it's not
>> > matching (perhaps because of handling  __device_builtin__ vs
>> > device_builtin differently in the AST matchers)?
>> >
>> > ~Aaron
>> >
>> >>
>> >> Thanks,
>> >> Oliver
>> >> _______________________________________________
>> >> cfe-dev mailing list
>> >> cfe-dev at lists.llvm.org
>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>


More information about the cfe-dev mailing list