This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC PATCH] Fix middle-end/6963
- From: Richard Henderson <rth at redhat dot com>
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Alan Modra <amodra at bigpond dot net dot au>, Ulrich dot Weigand at de dot ibm dot com, Mark Mitchell <mark at codesourcery dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 28 Jun 2002 16:30:21 -0700
- Subject: Re: [RFC PATCH] Fix middle-end/6963
- References: <rth@redhat.com> <200206282204.SAA24600@makai.watson.ibm.com>
On Fri, Jun 28, 2002 at 06:04:40PM -0400, David Edelsohn wrote:
> You're suggesting creating the operand in the define_expand using
> gen_reg_rtx() instead of assign_stack_temp() and then letting reload place
> that pseudo in a MEM because of the constraint?
Yes. You'd use the X constraint when the pseudo isn't needed.
If you like, arrange for all of these instructions to use the
same pseudo, which will let them use the same memory slot. That
may be more complex than you wish just to fix the bug on the
branch.
> It seems strange to generate a pseudo reg that is suppose to match
> a memory_operand predicate, but it appears to work. The predicate did not
> cause a problem for the testcase, but should I use a less strict predicate
> or keep it memory_operand?
Err, it shouldn't work. Look at the top of memory_operand:
if (! reload_completed)
/* Note that no SUBREG is a memory operand before end of reload pass,
because (SUBREG (MEM...)) forces reloading into a register. */
return GET_CODE (op) == MEM && general_operand (op, mode);
You should use nonimmediate_operand, since the operand is
a register before reload and a memory after.
Hmm. Actually, I don't know what happens in the case that
the X alternative is used. You'll have to experiment here.
You may wind up using no predicate.
r~