On Sun, May 8, 2016 at 4:09 PM, Rob Clark wrote:
> On Sun, May 8, 2016 at 3:10 PM, Jason Ekstrand wrote:
>> Before you push this, of like to register my official skepticism as to
>> whether or not this is the right fix. Given that the end block is special,
>> anyone who depends on iterating over
On Sun, May 8, 2016 at 3:10 PM, Jason Ekstrand wrote:
> Before you push this, of like to register my official skepticism as to
> whether or not this is the right fix. Given that the end block is special,
> anyone who depends on iterating over it should know that and handle it
> specially anyway.
Before you push this, of like to register my official skepticism as to
whether or not this is the right fix. Given that the end block is special,
anyone who depends on iterating over it should know that and handle it
specially anyway. I'm pretty sure that block numbering is the only thing
that act
Hi Rob,
On jue, 2016-05-05 at 14:40 -0400, Rob Clark wrote:
> From: Rob Clark
>
> With the switch to new block iterator macro, we silently stopped
> iterating over the end-block. Which caused nir_index_blocks() to not
> index the end-block. Resulting in funny looking nir_print's like:
>
> imp
From: Rob Clark
With the switch to new block iterator macro, we silently stopped
iterating over the end-block. Which caused nir_index_blocks() to not
index the end-block. Resulting in funny looking nir_print's like:
impl main {
block block_0:
/* preds: */
intrinsic copy
