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]

Re: [PATCH, MIPS] Move patterns involving truncate out of "truncate section"


Richard Sandiford writes:
> OK, you've convinced me that this makes sense for truncated inputs.

Thanks.

> It sounds like your new patterns are in the "truncating extraction"
> category too, so I'd be happy for them to go in the same section.

Actually, it's the other kind but it turns out that I don't even have to add
new patterns[1].  It's really just an insn that can be emitted in
*extend{si,di}_truncate<mode> rather than splitting.

[1] I am actually adding a pattern *extendhi_truncateqi but only because it's
missing for HI mode so I couldn't extend it for EXTS.

> I'm not flat-out opposed to your change.  I just wanted to try to explain
> the current situation a bit.  Let me know if you're not convinced.

No, I think I am convinced.  What I was saying about this being a property of
the operation only works for *ashr_trunc<mode> pattern cleanly but this
pattern is probably unnecessary ever since TARGET_MODE_REP_EXTENDED (I need to
actually check this).  The other two are more of the "truncating extraction"
type, especially *<optab>_trunc<mode>_exts, which even generates an extraction
insn.

(BTW, with TARGET_MODE_REP_EXTENDED we can probably perform the transformation
in *lshr32_trun<mode> in the middle-end.)

Adam


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]