On Wed, Dec 17, 2014 at 11:51 AM, Connor Abbott <cwabbo...@gmail.com> wrote: > One thing I'm a little worried about is that passes might forget to > require the right metadata, and they'll just happen to work since the > pass before also requires the same metadata and preserves it. I think > a good thing to do to combat this is to have a debug mode that dirties > *all* the metadata in nir_metadata_preserve(), even the stuff the > caller asks us to preserve, and actually goes and destroys it/somehow > makes it garbage so that passes that forget to require the right > metadata will fail spectacularly. The other, more insidious, issue is > passes accidentally preserving metadata that the author didn't realize > they invalidated. We could solve this by somehow re-calculating the > metadata in nir_metadata_preserve() and comparing it to the old > metadata before trashing it, but I'm not as clear on how that would > work and it seems like a lot more work so I'm fine with leaving it out > for now. I'd like this to happen whenever we enable nir_validate > (#ifdef DEBUG?), but I'll leave figuring out how to enable it up to > you.
I don't really think this is a big concern. We called calculate_cfg()/calculate_live_intervals() in the i965 driver in a bunch of optimization passes. In most cases forgetting to call them lead to instant segfaults. It was only rarely that it wasn't entirely obvious what was going on, but even then noticing that we're reading some live variable information without generating it makes it pretty easy to spot. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev