[valgrind] [Bug 352364] ppc64: --expensive-definedness-checks=yes is not quite working here

[Mark Wielaard]

https://bugs.kde.org/show_bug.cgi?id=352364

Mark Wielaard  changed:

   What|Removed |Added

 CC||m...@klomp.org
 Ever confirmed|0   |1
 Status|REPORTED|CONFIRMED

--- Comment #6 from Mark Wielaard  ---
Added a prereq to skip memcheck/tests/bug340392.vgtest on power:

commit 94960fae328bc82fb1ea51ffb9273ad5f25936d2 (HEAD -> master)
Author: Mark Wielaard 
Date:   Mon Oct 30 21:41:57 2023 +0100

bug340392 doesn't work on power because of bug352364

Add a prereq to bug340392.vgtest to skip on Power for now.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 352364] ppc64: --expensive-definedness-checks=yes is not quite working here

[Mark Wielaard]

https://bugs.kde.org/show_bug.cgi?id=352364

Mark Wielaard  changed:

   What|Removed |Added

   See Also||https://bugs.kde.org/show_b
   ||ug.cgi?id=340392

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 352364] ppc64: --expensive-definedness-checks=yes is not quite working here

[Julian Seward]

https://bugs.kde.org/show_bug.cgi?id=352364

--- Comment #5 from Julian Seward  ---
We are going to have to defer this till after 3.13.  It requires
some non-trivial reworking of either IR optimisation specific to
POWER, or to the POWER condition code handling, or both.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 352364] ppc64: --expensive-definedness-checks=yes is not quite working here

[Carl Love via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=352364

Carl Love  changed:

   What|Removed |Added

 CC||c...@us.ibm.com

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 352364] ppc64: --expensive-definedness-checks=yes is not quite working here

[Julian Seward via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=352364

--- Comment #4 from Julian Seward  ---
On contemplation, it is probably easiest to fix this in ir_opt.c
by doing an IR-to-IR transformation pass that, following the example
in comment 3, transforms

   CmpEQ32( select-bit-1-of( CmpORD64U(x,y) ), 0x0 )

to

   CmpNE64(x,y)

where "select-bit-1-of" incorporates all the size-changing and masking
gunk (64to8, then 8Uto32, then And32 with 2, then Xor32 with 2).  We
could be cleverer about the size-changing and masking bits, for
example declaring CmpORD64U to produce a I32 typed result, since
matching IR patterns is hard work and it's easy to miss cases.  With
that change the example simplifies to

  t54 = CmpORD64U(t48,0xCD:I64)
  if (CmpEQ32(Xor32(And32(t54,0x2:I32),0x2:I32),0x0:I32)) ...

and if we get rid of the Xor32 and instead compare the extracted
value with 2:

  t54 = CmpORD64U(t48,0xCD:I64)
  if (CmpEQ32( And32(t54,0x2:I32), 0x2:I32)) ...

That would make the matching problem easier.  Furthermore if we
normalise And32 and CmpEQ32 nodes so that if just one of the args is a
constant than it is on the right, then there are no L-vs-R structural
variants to consider.

There is a bunch of infrastructure in ir_opt.c, starting at line 5953,
for "MSVC specific transformation hacks", that would form a useful
starting point.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 352364] ppc64: --expensive-definedness-checks=yes is not quite working here

[Julian Seward via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=352364

--- Comment #3 from Julian Seward  ---
In this example, "cmpld ; bne" translates to essentially this

   // the cmpld
   t54 = 64to8(CmpORD64U(t48,0xCD:I64))

   // the bne
   if (CmpEQ32(Xor32(And32(8Uto32(t54),0x2:I32),0x2:I32),0x0:I32))
  { PUT(1296) = 0x13C4:I64; exit-Boring }

CmpORD64U produces a value that is either 8, 4 or 2, with 8 meaning
"<", 4 meaning ">" and 2 meaning "=".  The bne translation then
inspects t54 bit 1 (intel encoding) (hence the use of 0x2).  This
completely obscures the fact that what we really want is simply

   if (CmpNE64(t48,0xCD:I64) { PUT(1296) = 0x13C4:I64; exit-Boring }

The tricky part is to change the generated IR so that it directly
exposes the condition on which the branch is based, yet make it
possible for later instructions to recover a correct value for CR0
.. CR7 should they wish to.  Maybe we should change the ppc front end
to use a thunk-based representation as most of the other front ends
do, since that does more or less facilitate all of the above.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 352364] ppc64: --expensive-definedness-checks=yes is not quite working here

[Will Schmidt via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=352364

Will Schmidt  changed:

   What|Removed |Added

 CC||will_schm...@vnet.ibm.com

-- 
You are receiving this mail because:
You are watching all bug changes.