Page MenuHomePhabricator

[Target][ARM] Fix VPT Block Pass miscompilation

Authored by Pierre-vh on Apr 9 2020, 6:44 AM.



This fixes a miscompilation I introduced in D75993: In that patch, I was switching back to a "T" predicate if an instruction in the "E" part of a VPT block was writing to VPR.

vpttet.s32	le, q3, r2
vcmpt.s32	ge, q3, r3
vstrwt.32	q0, [r4]
vcmpe.i32	eq, q3, q1       ; There was a vpnot before the vcmp, so its predicate became 'e' and the vpnot was removed
vstrwt.32	q2, [r4], #16   ; vcmp wrote to VPR, so the predicate became 'T' again -> this is incorrect

The correct code for above is this, instead:

vpttee.s32	le, q3, r2
vcmpt.s32	ge, q3, r3
vstrwt.32	q0, [r4]
vcmpe.i32	eq, q3, q1
vstrwe.32	q2, [r4], #16 ; even if vcmp wrote to vpr, we keep the 'E'

To fix this, I simply removed all of the logic related to "swapping predicates back to T" in the MVE VPT Block Insertion pass.

I also had to rewrite one test so it'd still have a vpttet block - the previous version of the test became a vpttee with this change.

Diff Detail

Event Timeline

Pierre-vh created this revision.Apr 9 2020, 6:44 AM

Have we got a test where there's two vcmps and vpnots to consider? I see quite a few test permutations, but I can't see this one.

Yeah, I thought that worked differently to how it does. I may have led you astray.


Can you keep the old test as another vpttee test too

Pierre-vh updated this revision to Diff 257264.Apr 14 2020, 3:24 AM
  • Rebasing the patch, so I can commit it earlier (I'll commit it with the VPT Optimisations pass which has already been approved)
  • Adding another test + restoring the old test (which produces a weird result, but it's fixed by the child revision)
dmgreen accepted this revision.Apr 14 2020, 6:08 AM

LGTM, Thanks

This revision is now accepted and ready to land.Apr 14 2020, 6:08 AM
This revision was automatically updated to reflect the committed changes.