RFC: failure of gcc.dg/funcorder.c on hppa64

[John David Anglin]

I'm wondering if a "middle-end" expert comment on this optimization problem.

The funcorder.c test fails on hppa64 because in the following function

static int q()
{
	int t=mem,r;
	r=e();
	if (t!=mem)
		link_error();
	return r;
}

the `if' is not eliminated.  `e()' is pure, so it should be eliminated.

On hppa64, `t' is promoted to long with a zero extend.  The `if' is a
SI mode comparison involving a subreg of `t'.  Only combine is able to
combine zero extends with a subreg in an `if', but this can't occur
across a function call.  The combine pass occurs after the final flow
graph analysis so even if combine were allowed to combine across pure
functions, the test would still fail because `q()' isn't recognized
as pure.  On ports where `t' isn't promoted, the `if' is eliminated
in the cse pass and `q()' is recognized as being pure.

Is there any hope of enhancing cse/gcse to deal with promoted variables
in a better way?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)