IA64 inline division question

[Steve Ellcey]

I think I have finally figured out what the bad code is when compiling
177.mesa with -O2 -minline-float-divide-min-latency, but I am not sure
what part of GCC is generating it or how to fix it so I thought I would
see if I can get some more help and/or advise.

I tracked the problem down to the general_textured_triangle routine in
mesa and to an interaction between the -minline-float-divide-min-latency
option and the -fcaller-saves option.  Only when these two options are
specified does GCC try to save and restore any floating point registers
around a call to gl_write_texture_span.

The saves look something like (ignoring bundling):

	addl r17 = 29016, r0    // 3072 *movdi_internal/2
	add r17 = r17, r12      // 3073 adddi3/1
	stf8 [r17] = f55        // 2938 *movdi_internal/10

and the restores look like:

	addl r21 = 29016, r0    // 3076 *movdi_internal/2
	add r21 = r21, r12      // 3077 adddi3/1
	ld8 r21 = [r21] // 3078 *movdi_internal/4
	setf.sig f55 = r21      // 2940 *movdi_internal/7

But this seems wrong because we are only saving and restoring the
significand part of f55, not the entire register.  Any idea on why we
are doing that?  I guess it is because we think the floating point
register contains an integer value, but does it?  When I look at where
the register is used elsewhere in the code it gets treated as a single
precision floating point value in those places:

	(p7) fmpy.s f55 = f6, f54       // 876  mf+112
	mov f55 = f0    // 856  *movsf_internal/1
	mov f22 = f55   // 858  *movsf_internal/1
	fma.s f36 = f44, f22, f55       // 1799 *maddsf4

So why is the save/restore done as a DImode instead of SFmode, which is
what the register actually contains?   For that matter, why isn't it
done with real spill/fill instructions?

Steve Ellcey
sje@cup.hp.com