[Mesa-dev] [PATCH 02/11] nir: Add a pass-running infastructure

[Ian Romanick]

On 10/28/2015 06:30 PM, Kenneth Graunke wrote:
> On Wednesday, October 28, 2015 05:04:07 PM Ian Romanick wrote:
>> On 10/28/2015 04:43 PM, Connor Abbott wrote:
>>> On Wed, Oct 28, 2015 at 7:06 PM, Ian Romanick <idr at freedesktop.org> wrote:
>>>> On 10/28/2015 02:32 PM, Jason Ekstrand wrote:
>>>>> ---
>>>>>  src/glsl/nir/nir.h      | 19 +++++++++++++++
>>>>>  src/glsl/nir/nir_pass.c | 64 ++++++++++++++++++++++++++++++++++++++++++++++++-
>>>>>  2 files changed, 82 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/src/glsl/nir/nir.h b/src/glsl/nir/nir.h
>>>>> index e3777f9..069c7c1 100644
>>>>> --- a/src/glsl/nir/nir.h
>>>>> +++ b/src/glsl/nir/nir.h
>>>>> @@ -1582,6 +1582,25 @@ typedef struct nir_shader {
>>>>>        foreach_list_typed(nir_function_overload, overload, node, \
>>>>>                           &(func)->overload_list)
>>>>>
>>>>> +typedef struct nir_pass {
>>>>
>>>> A couple years ago Kristian, with the support of everyone, waged a war
>>>> on 'typedef struct foo { ... } foo;'  Has this awful idiom really risen
>>>> from the dead?  Can we please send it back to the grave?
>>>
>>> (flamewar incoming!)
>>>
>>> Yes, it has, and no.
>>>
>>> In case you haven't read any NIR code, NIR uses this all over the
>>> place -- all of the core datastructures are typedef'd. The only
>>> argument I've heard against this practice, from Linus, is that it
>>> makes telling if a value is a lightweight thing, like an integer, or
>>> not. But this isn't the kernel; we don't use typedefs for integers at
>>
>> But that it is the way *this* project has done things.  We made a
>> conscious decision to do them that way.  I don't think you guys had any
>> right to unilaterally decide to change that.
> 
> I don't think it's as clear cut as that.  Most of the GLSL compiler was
> written in C++, and so the compiler code constantly referred to objects
> without using 'struct' or 'class'.  See every piece of code that deals
> with ir_variable, ir_assignment, and so on.

That is true, but I think that's okay.  Not saying struct or,
especially, class is "the" C++ idiom.  Just like not using this-> in
member functions is "the" C++ idiom.  I don't really care for either,
but it's what people who write C++ expect.  I recall that we started by
saying struct and class everywhere.  We stopped because people who write
more C++ added code that didn't say it, and the compiler complained
about the inconsistency.

In the end, we picked the idiom more common to that language.
Regardless of individual style choices, an overall strategy of lowering
the per-language barrier of entry for people familiar with that language
is sound.  Certainly none of the unusual Mesa style choices have found
their way into our Python code. :)

> When Connor wrote NIR in C, he chose to make this similar to the
> existing code.  Instead of ir_variable, you have nir_variable - not
> "struct nir_variable".  Yes, it's different than most Mesa C code.
> But it's more similar to existing Mesa compiler code.
> 
> If people are that passionate about typedefs being good-or-evil, then
> we should just make a decision, and write patches to make the style
> what the majority of people working on the project want.
> 
> Personally, I think it would be much more interesting and worthwhile
> to discuss the merits of a pass management infrastructure, and offer
> feedback about Jason's design and implementation...
> 
> Let's try to keep it civil...burning bridges with our fellow hackers
> is another great way to wound a project...
> 
> --Ken
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20151030/19f9154d/attachment-0001.sig>