<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 16, 2016 at 2:01 AM, Iago Toral <span dir="ltr"><<a href="mailto:itoral@igalia.com" target="_blank">itoral@igalia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 2016-03-16 at 09:48 +0100, Samuel Iglesias Gonsálvez wrote:<br>
><br>
> On 15/03/16 08:41, Iago Toral wrote:<br>
> > On Mon, 2016-03-14 at 17:33 -0700, Jason Ekstrand wrote:<br>
> [...]<br>
> >> +   nir_alu_type type; + union { -      uint32_t u; -<br>
> >> int32_t i; -      float f; +      uint64_t u; +      int64_t i; +<br>
> >> double d; } data; } nir_search_constant;<br>
> ><br>
> > Maybe we should rename these to u64, i64 as f64 like you suggested<br>
> > for a similar case in another patch?<br>
> ><br>
><br>
> We decided to do the following changes to this patch series (among the<br>
> others already agreed): rename these fields and add the inline helper<br>
> functions to get type size and base type from nir_alu_type enum<br>
> values. So the rest of the fp64 patches will have those changes<br>
> already and everything would be easier to maintain.<br>
><br>
> One question for Jason: Should we squash all the patches of this<br>
> series in a single commit as originally proposed? I'd rather have them<br>
> separately so we understand what each patch does in case of a git<br>
> bisect, however I don't have a strong opinion against squashing.<br>
<br>
</span>At the very least we should squash the one for the copy-propagation pass<br>
with the new opcodes, otherwise we'd break the build.<br>
<br>
The main concern with squashing everything is that it is going to be a<br>
huge patch and it is going to be difficult to make sense of it like that<br>
for anyone who tracks something down to it, but otherwise we are going<br>
to break some things in between which is also not ideal...<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Right.  Let's squash the minimum.  I think we can probably keep copy propagation and nir_search mostly out of the squash.  Right now, nothing uses values of any size other than 32 so it should be safe to leave them separate for the most part.<br></div><div>--Jason <br></div></div><br></div></div>