public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/16815] New: MIPS n32/n64 inefficient code for float arguments
@ 2004-07-29  2:05 wilson at gcc dot gnu dot org
  2004-07-29  2:08 ` [Bug middle-end/16815] " pinskia at gcc dot gnu dot org
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: wilson at gcc dot gnu dot org @ 2004-07-29  2:05 UTC (permalink / raw)
  To: gcc-bugs

If you compile code using a float argument, and compile with optimization for
the n32 or n64 ABIs, then gcc-3.4 and later will emit code that stores the float
arg onto the stack, and then  loads it back into a register.

A trivial example
float
sub (float f, float g)
{
  return f + g;
}
gives
        swc1    $f12,0($sp)
        swc1    $f13,16($sp)
        lwc1    $f1,16($sp)
        lwc1    $f0,0($sp)
        add.s   $f0,$f0,$f1

The problem here is related to the definition of the BLOCK_REG_PADDING macro in
the mips port.  A float arg has natural alignment in a register, but when
big-endian, it has the "wrong" alignment in a stack slot.  In this case,
FUNCTION_ARG_PADDING and BLOCK_REG_PADDING return different values.  There is
code in function.c in assign_parms_setup_block_p that forces values onto the
stack if they have the wrong padding, but there are a number of things wrong
here.  It is testing locate->where_pad, but this is from FUNCTION_ARG_PADDING,
not BLOCK_REG_PADDING.  If the argument was passed in a reg, then
FUNCTION_ARG_PADDING should be irrelevant here.  It should be testing
BLOCK_REG_PADDING instead, and possibly only if the arg was passed in a
register.  Also, there is the issue of why we are storing it to the stack,
instead of just shifting it into position as is done in calls.c.  I am unsure
what the purpose of this code is, so I am unsure what exact fix is needed here.
 I haven't tried to fully analyze the code yet.

I am mainly filing this to document the problem, so I won't forget it.  I
noticed it while doing other work.

I don't care whether this gets fixed in gcc-3.4.

-- 
           Summary: MIPS n32/n64 inefficient code for float arguments
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: wilson at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: mips64-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16815


^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2004-10-07  5:37 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-07-29  2:05 [Bug middle-end/16815] New: MIPS n32/n64 inefficient code for float arguments wilson at gcc dot gnu dot org
2004-07-29  2:08 ` [Bug middle-end/16815] " pinskia at gcc dot gnu dot org
2004-07-29  2:10 ` wilson at gcc dot gnu dot org
2004-07-29  2:25 ` wilson at tuliptree dot org
2004-07-29  4:26 ` pinskia at gcc dot gnu dot org
2004-09-30 11:19 ` giovannibajo at libero dot it
2004-10-07  5:34 ` cvs-commit at gcc dot gnu dot org
2004-10-07  5:37 ` rsandifo at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).