On 09/24/2013 04:13 PM, Kenneth Graunke wrote: > On 09/24/2013 03:42 PM, Ian Romanick wrote: >> On 09/24/2013 03:38 PM, Matt Turner wrote: >>> On Tue, Sep 24, 2013 at 2:41 PM, Ian Romanick <i...@freedesktop.org> wrote: >>>> For our own edification, we should add some feedback in the >>>> INTEL_DEBUG=perf case. If there is any case that an ADDC (or SUBB) from >>>> the frontend doesn't get merged with an add, we should generate a perf >>>> warning. This probably indicates a failing of the optimization pass. >>> >>> The peephole is called for every add emitted after we've seen an ADDC >>> or SUBB, so it's not unexpected for the pass to not change anything. >>> >>> Also, if only the carry is used dead code elimination at the IR level >>> will remove the add, so no chance to peephole. >> >> Hm... that makes sense. I was thinking of something at the very end >> that would notice that the ADDC and ADD hadn't been merged and complain. >> Maybe it would only complain if both the ADDC and ADD survived to the >> end? Dunno... it was just an idea. > > If we detect an ADDC/ADD that could have been merged, we should just > merge them. If they couldn't have been merged, there's nothing to > complain about... > > Essentially, writing a detector for things we haven't optimized is the > same complexity as actually optimizing them.
I'm not trying to belabor the point, but... Even in the presence of code motion and CSE? Detection isn't necessarily the same level of complexity. You could imagine tagging both instructions with a unique value from the original ir_call, then checking whether multiple instructions exist with the same tag. We've had a few cases where we thought optimization or lowering passes were doing one thing, but we were surprised when we found cases that they were doing another. In those cases, it took quite a bit of effort to find out that "another" thing was happening. We should keep that in mind as we make new passes like this. How can the code we write help us debug strange behaviors later? *shrug* _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
