Re: minor code-quality regression vs. 2.95

[Jeffrey A Law <law@cygnus.com>]

  In message <20000412160823.A13160@cpopetz.com>you write:
  > On Tue, Apr 11, 2000 at 09:45:41PM -0700, Zack Weinberg wrote:
  > > This function:
  > > 
  > > long long blocks (long long bytes) { return bytes / 512; }
  > > 
  > > compiles as follows with 2.95:
  > > 
  > > blocks:
  > > 	movl 4(%esp),%eax
  > > 	movl 8(%esp),%edx
  > > 	testl %edx,%edx
  > > 	jge .L3
  > > 	addl $511,%eax
  > > 	adcl $0,%edx
  > > L3:
  > > 	shrdl $9,%edx,%eax
  > > 	sarl $9,%edx
  > > 	ret
  > > 
  > > and with the 20000408 CVS tree:
  > > 
  > > blocks:
  > > 	movl	8(%esp), %edx
  > > 	movl	4(%esp), %eax
  > > 	cmpl	$0, %edx
  > > 	jg	.L3
  > > 	testl	%edx, %edx
  > > 	jns	.L3
  > > 	addl	$511, %eax
  > > 	adcl	$0, %edx
  > > L3:
  > > 	shrdl	$9, %edx, %eax
  > > 	sarl	$9, %edx
  > > 	ret
  > > 
  > > Notice the additional compare and test in the 2.96 code.  
  > > 
  > > I can't make any sense at all of the RTL.
  > 
  > ix86_expand_branch is emitting the long long compare like this:
  > 
  >          * a < b =>
  >          *    if (hi(a) < hi(b)) goto true; 
  >          *    if (hi(a) > hi(b)) goto false;
  >          *    if (lo(a) < lo(b)) goto true;
  > 
  > In the above case, the third jump can be turned into an uncoditional jump b
  > y
  > cse, which means the first test/jump could be eliminated _if_ it were emitt
  > ed
  > directly before the last one (i.e. swap the first two statements above.)
Maybe we should instead look at how we could improve our existing optimizers
to handle this situation.

For example, it might be possible to have thread_jumps detect this case.

Or somehow have life_analysis be aware that its actions can simplify the cfg
and account for those changes (by modifying the cfg and updating life info
appropriately).

jeff