[Mesa-dev] [PATCH 09/10] i965/fs: Add a peephole pass to combine ADD with ADDC/SUBB.
Ian Romanick
idr at freedesktop.org
Wed Sep 25 15:26:44 PDT 2013
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 <idr at 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*
More information about the mesa-dev
mailing list