This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 3/4, MIPS] Move clear_upper32* patterns to the and patterns
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Adam Nemet <anemet at caviumnetworks dot com>
- Cc: Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Sun, 02 Aug 2009 20:46:58 +0100
- Subject: Re: [PATCH 3/4, MIPS] Move clear_upper32* patterns to the and patterns
- References: <19057.62127.907350.916479@ropi.home> <o7prbi9d60.fsf@ropi.home> <873a8d99ui.fsf@firetop.home> <19058.18643.649605.578065@ropi.home> <4A732411.7020800@redhat.com> <19059.35550.273420.635208@ropi.home>
Adam Nemet <anemet@caviumnetworks.com> writes:
> Richard Henderson writes:
>> How about merging all the patterns? E.g.
>
> I tried working out the details, this is where it stands. It passes
> ext-[4567].c tests from the MIPS testsuite but I haven't done any further
> testing.
Hmm. If we do this, we should do it for all combinations (i.e. have
patterns for TARGET_MIPS16 || !ISA_HAS_EXT_DEXT too). And MIPS16 has
the added complication that ZEB and ZEH are only for GENERATE_MIPS16E;
shifts are needed otherwise. All in all, I don't take back what I said
about it not being easy to do this cleanly. ;)
I was half-way through a patch that added support for the other cases,
but it just doesn't feel right. It seems like we're going to great
lengths to work around a deficiency in the IR (that we can't use
zero_extend for some zero extensions.) Maybe that's just something
we have to live with, but let me think about this a bit first?
(I know that's famous last words, what with the still-unresolved
$gp/long-branch issue ;(.)
Richard