[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 213685] Undefined value propagates past dependency breaking
From:       Julian Seward <jseward () acm ! org>
Date:       2010-09-30 23:23:23
Message-ID: 20100930232323.7CE746E5DB () immanuel ! kde ! org
[Download RAW message or body]

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





--- Comment #5 from Julian Seward <jseward acm org>  2010-10-01 01:23:21 ---
(In reply to comment #2)
> The official list of dependency-breaking instructions [...] is:

Hmm, it's not so simple though.  You want dependency breaking on the
pcmpeqb insn in comment 1, yet it isn't part of the list.  The set of
dependency-breaking operations that we actually need is a superset of
the official list, and it is phrased in terms of VEX IR primops, not
in terms of Intel instructions.

To find potential opportunities to find such IR primop applications,
I put the following patch in the IR constant folder

Index: priv/ir_opt.c
===================================================================
--- priv/ir_opt.c       (revision 2055)
+++ priv/ir_opt.c       (working copy)
@@ -1618,6 +1618,12 @@
       }
    }

+   if (e == e2 && e->tag == Iex_Binop 
+       && sameIRTemps(e->Iex.Binop.arg1, e->Iex.Binop.arg2)) {
+      vex_printf("IDENT: ");
+      ppIRExpr(e); vex_printf("\n");
+   }
+
    if (DEBUG_IROPT && e2 != e) {
       vex_printf("FOLD: "); 
       ppIRExpr(e); vex_printf("  ->  ");

It finds 'binop(t,t)' patterns that might be foldable.  On a run
of Firefox on x86_64-linux it picked up the following

IDENT: CmpEQ64(t24,t24)
IDENT: CmpEQ8x16(t13,t13)
IDENT: CmpF64(t10,t10)
IDENT: OrV128(t101,t101)
IDENT: Sub64F0x2(t30,t30)
IDENT: Sub64(t13,t13)

and from example 1 we have CmpEQ8x8 too.  I don't think I can be
bothered with the floating point ones (CmpF64, Sub64F0x2) as that
tends to be more complex, but the others might be foldable.  A good
thing to do would be to run a bunch of codec-y code with the above
patch in place, and see if any more cases pop out, so they can all
be fixed at once.

FTR, the constant folder already has rules of the form

   op(t,t) ==> t 
   for op in And64, And32, And8, Or64, Or32, Or16, Or8, Max32U

and

   op(t,t) ==> 0
   for op in Xor64, Xor32, Xor16, Xor8, XorV128, Sub32

which is probably why you were unable to exhibit the problem using
any xor instructions.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]