<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 28, 2015 at 11:20 PM, Eric Anholt <span dir="ltr"><<a href="mailto:eric@anholt.net" target="_blank">eric@anholt.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> writes:<br>
<br>
> I've got a patch I cooked up today that generalizes this a bit.  I haven't<br>
> sent it yet because it lacks shader-db statistics.  That said, I'm fine<br>
> with merging this in the mean time.<br>
<br>
</span>Not sure what generalization you're working on, but something that let<br>
me have "any sort of bool" as an expression node, and that "and(flt(a,<br>
b), flt(c, d))" was recognized as a bool would be nice for some of these<br>
patterns.  I was wondering if band/bor operations that were only defined<br>
on bool arguments would be a good idea (even though they'd codegen just<br>
like normal iand/ior), but then I got to thinking that this sounds like<br>
just a specific case of generally wanting possible-value categorization<br>
for SSA nodes.<br>
</blockquote></div><br></div><div class="gmail_extra">Yeah, that's what it does.  It's an extension to the current system to allow you to specify that a variable must match a certain type.  I just sent the series.<br></div><div class="gmail_extra">--Jason<br></div><div class="gmail_extra"><br></div></div>