Re: gcc/1532: Redundant compare instructions on i386

[Richard Henderson <rth at redhat dot com>]

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.

> 1) Comparisons are represented with different modes for purposes of
>    permitting future optimization, but are otherwise implemented by
>    the same underlying instruction.

This isn't really correct.  Lots of instructions set *some* flags
bits, but not all instructions set all flags bits in useful ways.
The different modes describe how the flags will be used, and thus
constrain which insns may be used to generate the flags.  This is
most apparent when you look at the combination patterns that do
add+compare and the like.

> 3) We want the compiler to eliminate obvious duplication in setting
>    the comparison flags.  That is, the compiler should recognize when
>    one compare instruction will produce the same result as a previous
>    compare instruction.
>    a) It should do this despite any mode differences.
>    b) It should do this even though the result goes to a hard
>       register.
>    c) It should not do this in the usual GCSE way, which involves
>       copying the value to a pseudo-register, because if that
>       pseudo-register is used after eflags has been clobbered the
>       resulting code will almost certainly be worse.

Agreed.

> There is some other awful code in this test case which I haven't even
> looked at yet, a useless jump to the next instruction:
> 
> 	je	.L1
> .L2:
> .L1:
> 
> I assume that is a separate problem, probably related to inlining.

I would assume.  Not sure exactly what would cause that...
It's possible there's something in the rtl between L2 and L1
seen by the optimizers but which produces no assembly.  If
so, there's probably not much to fix there.


r~