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

https://bugs.kde.org/show_bug.cgi?id=352364 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org Ever confirmed|0

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

https://bugs.kde.org/show_bug.cgi?id=352364 Mark Wielaard changed: What|Removed |Added See Also||https://bugs.kde.org/show_b

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

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

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

https://bugs.kde.org/show_bug.cgi?id=352364 Carl Love changed: What|Removed |Added CC||c...@us.ibm.com -- You are

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

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(

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

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

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

https://bugs.kde.org/show_bug.cgi?id=352364 Will Schmidt changed: What|Removed |Added CC|