llvm dev - May 2010 - [LLVMdev] Attention: About to Break SystemZ and possibly other Back Ends

Hi,

Attached is a patch I'm testing. It changes how
"MachineFrameInfo::HasCalls" is calculated. Basically, the way
it's calculated now is in PEI. And it only looks for frame adjustments (or
inline ASM) to determine if the function has a call or not. This way is much
more accurate and occurs much sooner. But it breaks this test:

	test/CodeGen/SystemZ/2009-07-10-BadIncomingArgOffset.ll

(See below for the output with this patch.)

The problem is that SystemZ is using "hasCalls()" in the back end to
determine if a frame pointer is needed or not. My guess is that several of the
places where it calls hasCalls() should really be hasFP(). I don't have
enough expertise in all of the back ends to determine if the call should be
"hasFP" or "hasCalls". I need the respective back end owners
to perform an audit of their code. This can be done even before my patch goes in
(it's not ready yet).

Please look at all calls to hasCalls() in the back end and determine if it
should remain that or should be changed to hasFP() instead, given that
hasCalls() is more accurate and not just indicating that there's a frame in
the function.

-bw

Here is the new output:

	.file
"/Volumes/Sandbox/llvm/llvm.src/test/CodeGen/SystemZ/2009-07-10-BadIncomingArgOffset.ll"
	.text
	.globl	mp_mul_radix_test_bb3
	.align	2
	.type	mp_mul_radix_test_bb3, at function
mp_mul_radix_test_bb3:                  # @mp_mul_radix_test_bb3
# BB#0:                                 # %newFuncRoot
	stmg	%r6, %r15, 48(%r15)
	aghi	%r15, -160
                                        # kill: R3W<def> R3D<kill>
	lr	%r12, %r2
	lg	%r11, 328(%r15)
	lg	%r1, 320(%r15)
	lgr	%r10, %r4
	lgfr	%r9, %r3
	lghi	%r3, -1
	lgr	%r2, %r9
	lgr	%r4, %r1
	brasl	%r14, rdft
	lgfr	%r2, %r12
	lgr	%r3, %r9
	lgr	%r4, %r10
	brasl	%r14, mp_mul_d2i_test
	std	%f0, 0(%r11)
	lmg	%r6, %r15, 208(%r15)
	br	%r14
.Ltmp0:
	.size	mp_mul_radix_test_bb3, .Ltmp0-mp_mul_radix_test_bb3


	.section	.note.GNU-stack,"", at progbits

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: p.txt
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100513/53f2a6f6/attachment.txt>
-------------- next part --------------

Hi, Bill
> Please look at all calls to hasCalls() in the back end and determine if it
should remain that or should be changed to hasFP() instead, given that
hasCalls() is more accurate and not just indicating that there's a frame in
the function.
It looks like hasCalls() returns false with your change, right?

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University