On Tue, Sep 26, 2017 at 6:30 AM, Samuel Pitoiset <samuel.pitoi...@gmail.com> wrote: > > > On 09/26/2017 12:29 PM, Juan A. Suarez Romero wrote: >> >> On Mon, 2017-05-01 at 12:11 -0400, Ilia Mirkin wrote: >>> >>> On Mon, May 1, 2017 at 12:09 PM, Samuel Pitoiset >>> <samuel.pitoi...@gmail.com> wrote: >>>> >>>> On 05/01/2017 05:59 PM, Ilia Mirkin wrote: >>>>> >>>>> >>>>> I think this is off. It shouldn't matter what the code sequence is, >>>>> it's all representable. You need to teach replaceZero to not mess >>>>> things up for SHLADD's src(1). >>>> >>>> >>>> >>>> It's representable but stupid to do it. We should keep the ADD there and >>>> this also avoids a workaround in the replaceZero logic just for that. >>>> >>>> IMHO, this is the better solution. >>> >>> >>> Yes, that would be a better optimization. However at this stage, you >>> have a y = SHL(x, 0) + ADD(y, z). I think it makes sense to combine >>> them into one and let DCE take care of it. >>> >>> Ideally we wouldn't get into such a situation, but the real issue is >>> that a perfectly representable (if dumb) instruction like SHLADD(x, 0, >>> y) gets messed up by replaceZero. We should fix replaceZero. We should >>> also try to avoid generating such stupid instructions. >>> >> >> So what was the final conclusion for this patch? Was replaceZero fixed? > > > I don't think it has been fixed, but I could be wrong.
https://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/nouveau/codegen?id=82e77d4e4484b5d4f6a7b4751a17c882e6d2ad69 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev