Connor Abbott <[email protected]> writes: > On Thu, Dec 18, 2014 at 1:49 PM, Eric Anholt <[email protected]> wrote: >> Connor Abbott <[email protected]> writes: >> >>> On Thu, Dec 18, 2014 at 2:01 AM, Eric Anholt <[email protected]> wrote: >>>> Jason Ekstrand <[email protected]> writes: >>>> >>>>> From: Connor Abbott <[email protected]> >>>>> >>>>> This is similar to ir_validate.cpp. >>>>> >>>>> v2: Jason Ekstrand <[email protected]>: >>>>> whitespace fixes >>>> >>>> I have again not reviewed the control flow bits. Couple of questions I >>>> had, though: >>>> >>>>> +static void >>>>> +validate_var_use(nir_variable *var, validate_state *state) >>>>> +{ >>>>> + if (var->data.mode == nir_var_local) { >>>>> + struct hash_entry *entry = >>>>> + _mesa_hash_table_search(state->var_defs, >>>>> _mesa_hash_pointer(var), >>>>> + var); >>>>> + >>>>> + assert(entry); >>>>> + assert((nir_function_impl *) entry->data == state->impl); >>>>> + } >>>>> +} >>>> >>>> Is there guaranteed to be a def of a local variable before a use? It >>>> would be undefined execution behavior, but not assertion failure >>>> quality, right? >>> >>> Yes, that's correct - there are no guarantees about this for variables >>> and registers. For SSA values, the definition should always dominate >>> the use (see the TODO about that) because a lot of SSA algorithms >>> assume that, so we model the use-before-def case by pointing the use >>> to a nir_ssa_undef_instr. >> >> OK, so it seems like this validation needs to be dropped. > > No, this isn't validating what you think it's validating. This > function is called every time a variable dereference happens, and > checks that the dereference is in the same function implementation as > the definition of the variable. Maybe we can add a && "deferencing a > local variable defined in a different function" to the assert to make > it clear what what's happening.
Ah, I was confused by the name of the table being "defs". var_decls might be better.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
