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: [IA-64 PATCH] PR rtl-opt/14261: ifcvt.c vs emit_move_insn.


On Sun, 2006-02-26 at 06:53, Roger Sayle wrote:
> The "miscommunication" then, is what is the middle-end allowed to
> pass emit_move_insn as a source or destination.

Roughly anything accepted by general_operand.  A zero_extract is not a
general operand.

I don't think this patch is the right approach.  The ia64 movdi pattern
should not be expected to handle something that isn't a valid general
operand.  If we have to fix the ia64.md file to handle this, then we
need to fix all md files.

I think the real problem is in noce_emit_move_insn.  It is trying hard
to be able to emit any kind of instruction, but it doesn't get all of
the details right.

Looking at this again, I see two possible solutions that don't look very
hard.

The first one is the recog_combine approach.  Instead of calling
recog_memoized, call recog directly, passing in a pointer for the
num_clobbers_to_add argument.  The pattern will then be successfully
recognized, and num_clobbers_to_add will be set to 1.  We then manually
add one clobber, and everyone is happy.  This will make the code more
robust, and may even eliminate the need for some of the other hackery
that is already there, but it would be hard to prove it.  There is a
tweak needed to the ia64.md file to make this work.  The shift_mix4left
pattern needs to be rewritten to use a match_scratch, but it should have
been written this way in the first place.

The second one is to note that we already have special purpose code for
the case where the destination is a STRICT_LOW_PART, in which case we
call store_bit_field.  We can do the same thing for the case where the
destination is a ZERO_EXTRACT.  The code needs to be a little different
for this case.  A STRICT_LOW_PART always contains a SUBREG, and the code
is stripping off the SUBREG.  This part doesn't apply when we have a
ZERO_EXTRACT.  Otherwise, the two cases should be pretty similar.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com


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