This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 07/30/2013 12:47 PM, DJ Delorie wrote:
Well, you need to show why GCC is generating this and we need to evaluate whether or not it's safe. I'm very leery of anything using a PSImode SUBREG on a port where truncation is not a nop.+; Note: using POPM.A #1 is two bytes smaller than using POPX.A.... + +(define_insn "movsipsi2" + [(set (match_operand:PSI 0 "register_operand" "=r") + (subreg:PSI (match_operand:SI 1 "register_operand" "r") 0))] + "TARGET_LARGE" + "PUSH.W %H1 { PUSH.W %1 { POPM.A #1, %0" +)So how is this different fram (set (psi) (truncate:psi (si)))?It should be the same, of course. I typically look at what gcc *is* generating, not what it *should* be generating, though ;-) GCC does a lot of silly things these days.
I'm very aware that all pointer math happens in SImode. My point is you need to find out *why* pattern was needed, explain it to this list so that we can evaluate if it's the right solution. I brought up the issue from the mn102 port because there's some reasonable chance it's the same problem. If it is the same problem, then we can discuss which is the better solution or if we hate them both, look at what it might take to fix reload.+; This pattern is needed in order to avoid reload problems. +; It takes an SI pair of registers, adds a value to them, and +; then converts them into a single PSI register. + +(define_insn "addsipsi3" + [(set (subreg:SI (match_operand:PSI 0 "register_operand" "=&r") 0) + (plus:SI (match_operand:SI 1 "register_operand" "0") + (match_operand 2 "general_operand" "rmi"))) + (clobber (reg:CC CARRY)) + ] + "" + "ADD.W\t%L2, %L0 { ADDC.W\t%H2, %H0 { PUSH.W %H0 { PUSH.W %L0 { POPM.A #1, %0" +Is it possible the insns which resulted in adding this pattern came from trying to zero/sign extend the frame pointer, then the frame pointer gets eliminated and turns into a (plus (sp) (const_int)?It's possible that's one case, but *all* pointer math happens in SImode since the pointer_plus change went in. So this pattern happens a lot.
jeff
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |