Mark Mitchell wrote:
Mark Shinwell wrote:
The generated code for f originally looks like:
sll $2,$4,16
sra $2,$2,16
j $31
slt $2,$0,$2
After this patch, we end up with just:
j $31
slt $2,$0,$4
Nice!
To be clear, the case where the optimization you're working on is
interesting is when the ABI does not require that callers sign-extend
arguments to functions -- but we do it anyhow. Is that correct?
Actually, it looks as if the use of TARGET_PROMOTE_PROTOTYPES
(which causes arguments smaller than "int" to be extended to "int" size
upon calls) is what is introducing these extensions.
What I wondered about doing is adjusting that target hook so that
it was passed the whole FUNCTION_DECL rather than just the function
type -- in such cases perhaps a MIPS implementation of such a hook
could prevent these promotions in the first place. However that
appears tricky not least since the C++ front end calls the hook
on partially-constructed function declarations; care would have to be
taken that the hook didn't give inconsistent results upon such
declarations at this stage and any later stage (when the completed
declaration might perhaps be passed again to the hook). I haven't
examined these uses of the hook in detail, but it looks as if it is
probably rather subtle.
So perhaps the new combine code ought not do anything except when
TARGET_PROMOTE_PROTOTYPES is set: what I'm worried about here is whether
the patch could accidentally remove sign extensions (not introduced
by TARGET_PROMOTE_PROTOTYPES) that are needed for correctness.
Does anyone have any ideas to offer on this front? (I do wonder if
it might be possible to alter the MIPS backend so we didn't define
TARGET_PROMOTE_PROTOTYPES at all.)