<p dir="ltr"><br>
On Apr 12, 2016 7:52 AM, "Eirik Byrkjeflot Anonsen" <<a href="mailto:eirik@eirikba.org">eirik@eirikba.org</a>> wrote:<br>
><br>
> Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> writes:<br>
><br>
> > This tiny series converts nir_var_mode to be a bitfield instead of a<br>
> > regular enum and then converts two of the passes that currently take a mode<br>
> > to handle the new bitfield.  The reason for this is that a number of<br>
> > different passes want to be able to act on some subset of the modes and can<br>
> > run more efficiently if they are called once with that set rather than once<br>
> > per mode.<br>
> ><br>
> > I'm not 100% sold on making it a bitfield and asserting only one bit is set<br>
> > in nir_validate.  This isn't the standard pattern in the mesa compiler<br>
> > stack today so it may throw people off.  It still looks kind of strage to<br>
> > me.  On the other hand, it does have the potential to make things look<br>
> > nicer and gdb will pretty-print it for you.  For what it's worth, the<br>
> > Khronos group settled on using this pattern for bitfield-capable enums in<br>
> > Vulkan.  Rob seems to prefer this over a regular enum and using (1 << mode)<br>
> > everywhere so, unless there are major objections, we'll probably go with<br>
> > it.<br>
><br>
> Would it help to name them *_bit to signify the fact that they are bits<br>
> rather than values?</p>
<p dir="ltr">We could, but such a change would touch over half of NIR for, I think, marginal benefit.</p>
<p dir="ltr">> eirik<br>
</p>