This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc/1532: Redundant compare instructions on i386


In message <m3ektuknh6.fsf@gossamer.airs.com>, Ian Lance Taylor writes:
 >Richard Henderson <rth@redhat.com> writes:
 >
 >> On Tue, Jan 20, 2004 at 04:42:31PM -0500, Ian Lance Taylor wrote:
 >> > So I punted and wrote a quick pass in machine dependent reorg to
 >> > eliminate obvious duplicate comparison cases.  It works fine on this
 >> > test case--the resulting code is the same except that the redudant
 >> > comparison is eliminated.  But it kind of sucks because it doesn't do
 >> > any real dataflow analysis, so it will miss all but the most obvious
 >> > cases.
 >> 
 >> This is actually not bad, I think, simply because almost everything
 >> clobbers the flags, and therefore data can't flow very far at all.
 >> 
 >> About the only thing you could do better than what you did is to
 >> follow extended basic blocks.  I.e. follow jumps forward through
 >> jumps to blocks with only one incoming edge.
 >
 >Hmmm, that's true, but also the machine dependent reorg pass is so
 >late in the process.  It would be nice to do this before reload, at
 >least, since it can potentially free up a register which won't be
 >needed for the second compare.  Admittedly you can't do any math,
 >since that would clobber the flags register, but you can at least move
 >stuff around.  I dunno.  Maybe it won't make any difference in
 >practice.
FWIW, even when you fix the redundant compares, the compiler really ought
to thread all the paths to the switch statement to their ultimate
destinations -- we know at compile time which case will be taken for
each path to the switch statement.

>From looking at the tree-ssa dumps, we do manage to determine the switch's
value for each incoming path, but the threading code doesn't thread
through blocks with switch statements (I simply haven't written that
tiny bit of code yet):

  # BLOCK 3
  # PRED: 1 [50.0%]  (false,exec) 0 [29.0%]  (true,exec) 2 [100.0%]  
(fallthru,exec)
  # <D1081>_1 = PHI <2(1), 1(2), 0(0)>;
<L4>:;
  switch (<D1081>_1)
    {
      case 0: goto <L5>;
      case 1: goto <L6>;
      case 2: goto <L7>;
      default : goto <L8>;
    }
  # SUCC: 7 [25.0%]  (exec) 6 [25.0%]  (exec) 5 [25.0%]  (exec) 4 [25.0%]  
(exec)


So once I add that code to the jump threader you should get something like
this pseudo C out of the tree-ssa optimizers:

  if (i == j) goto L1; else goto L2;
L2:

  if (i > j) goto L3; else goto L4;

L4:
  goto L5;

L1:
  return i + j;

L3:
  return i;

L5:
  return j;



Anyway, I'll probably use this as a testcase when I cobble together
the code to thread jumps through switch statements.

jeff



  

























Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]