[cfe-commits] [patch] Add codegen for the __noop intrinsic

[Eli Friedman]

On Wed, Sep 26, 2012 at 8:10 AM, Nico Weber <thakis at chromium.org> wrote:
> On Wed, Sep 26, 2012 at 4:37 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>> On Wed, Sep 26, 2012 at 12:29 AM, Nico Weber <thakis at chromium.org> wrote:
>>> On Wed, Sep 26, 2012 at 4:24 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>>> On Tue, Sep 25, 2012 at 11:36 PM, Nico Weber <thakis at chromium.org> wrote:
>>>>> On Wed, Sep 26, 2012 at 3:06 PM, Nico Weber <thakis at chromium.org> wrote:
>>>>>> On Wed, Sep 26, 2012 at 2:49 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
>>>>>>> On Tue, Sep 25, 2012 at 10:05 PM, Nico Weber <thakis at chromium.org> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> similar to the __debugbreak patch, this adds codegen support for __noop.
>>>>>>>
>>>>>>> You don't actually have to call llvm.donothing... like the name says,
>>>>>>> it doesn't do anything. :)  "return RValue::get(0);" should be
>>>>>>> sufficient.
>>>>>>
>>>>>> My patch has nicer -S -emit-llvm output :-) But sure, I'll change it.
>>>>>>
>>>>>>>
>>>>>>> Do we actually perform semantic analysis correctly for __noop?
>>>>>>
>>>>>> Not completely.
>>>>>>
>>>>>>> In MSVC, are the arguments unevaluated in the semantic analysis sense?
>>>>>>
>>>>>> cl seems to do sema for __noop, __noop(3 + someclassinstanc) results
>>>>>> in a syntax error. So does wrapping a statement in __noop.
>>>>
>>>> How about something like the following?
>>>>
>>>> template<typename T> static void f() { T x = 10; }
>>>> void g() { __noop(f<void>()); }
>>>>
>>>> (By "unevaluated', I mean in the same sense that the operand of sizeof
>>>> is unevaluated.)
>>>
>>> This compiles fine with cl but currently errors out with clang:
>>>
>>> C:\src\chrome\src>type test.cc
>>> template<typename T> static void f() { T x = 10; }
>>> void g() { __noop(f<void>()); }
>>>
>>> C:\src\chrome\src>cl /c test.cc
>>> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86
>>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>>
>>> test.cc
>>>
>>> C:\src\chrome\src>..\..\llvm-ninja\bin\clang++.exe -c test.cc
>>> test.cc:2:19: error: argument type 'void' is incomplete
>>> void g() { __noop(f<void>()); }
>>>                   ^~~~~~~~~
>>> test.cc:1:42: error: variable has incomplete type 'void'
>>> template<typename T> static void f() { T x = 10; }
>>>                                          ^
>>> test.cc:2:19: note: in instantiation of function template
>>> specialization 'f<void>' requested here
>>> void g() { __noop(f<void>()); }
>>>                   ^
>>> 2 errors generated.
>>
>> That's what I was afraid of.  To get it right, you'll need to make the
>> parser recognize __noop as a keyword and parse it similarly to sizeof
>> (using EnterExpressionEvaluationContext to push an Unevaluated
>> context).
>
> The attached patch contains adds noop as UnaryExprOrTypeTraitExpr
> variant. That way it gets the unevaluated context for free. Is this an
> ok approach? (I still need to check how cl handles some things in the
> included test, so it's not a final patch, but it's pretty close.)

__noop parses like a call, not a unary operator... suppose someone
overloads "operator,". :)

-Eli