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 <[email protected]> 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. _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
