Dec 30 patch causes large performance regression on ia64

[Bernd Schmidt]

On Fri, 9 Feb 2001, Richard Kenner wrote:

>     might cause a 20% performance drop when running the 147.vortex benchmark
>     from SPEC95 on ia64-linux?
>
> No, not at all.  It could have a negative affect on stack usage, but
> shouldn't have an effect on execution speed other than a second-order
> effect in that if stack slots aren't shared, the data cache hit rate
> may go down, but that seems unlike to cause a 20% hit.

I tracked this down a while ago, but I haven't had a good idea how to solve
it yet.  A tiny change in initial rtl generation has a large effect on
performance.

The problem is that safe_from_p now knows more.  This, in turn, causes us
to generate slightly different code for certain COND_EXPRs.  Before, the
code for the "then" branch ended in a call; now there's an extra store in
the basic block.  The problem: if conversion doesn't deal with calls very
well; they have to end the block or we can't optimize.  And since this
situation is common in this particular benchmark, we end up with a drastic
performance drop.

I don't see an easy way to fix this properly.  So far, I've used the patch
below to restore performance to the previous level but it's an ugly hack.
It disallows the optimization that became possible when safe_from_p was
improved.

Ideas?


Bernd

Index: expr.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/expr.c,v
retrieving revision 1.295
diff -u -p -r1.295 expr.c
--- expr.c	2001/02/04 22:43:59	1.295
+++ expr.c	2001/02/27 13:10:44
@@ -8050,8 +8050,8 @@ expand_expr (exp, target, tmode, modifie
 		     || GET_CODE (original_target) == REG
 		     || TREE_ADDRESSABLE (type))
 #endif
-		 && ! (GET_CODE (original_target) == MEM
-		       && MEM_VOLATILE_P (original_target)))
+		 && (GET_CODE (original_target) != MEM
+		     || TREE_ADDRESSABLE (type)))
 	  temp = original_target;
 	else if (TREE_ADDRESSABLE (type))
 	  abort ();