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] Fix PR c/11420 (broken amd64 movabs*)


> On Thu, Jul 03, 2003 at 08:48:48AM -0700, Richard Henderson wrote:
> > On Thu, Jul 03, 2003 at 11:26:34AM +0200, Jakub Jelinek wrote:
> > > -  [(set (mem:SI (match_operand:DI 0 "x86_64_movabs_operand" "i,r,r"))
> > > -	(match_operand:SI 1 "nonmemory_operand" "a,er,i"))]
> > > +  [(set (mem:SI (match_operand:DI 0 "x86_64_movabs_operand" "i,r"))
> > > +	(match_operand:SI 1 "nonmemory_operand" "a,er"))]
> > 
> > The other thing that needs to happen here is that we shouldn't 
> > recognize this pattern at all if the mem is volatile and 
> > volatile_ok is false.
> > 
> > We currently mistakenly recognize regular move insns as movabs
> > patterns because of this.
> 
> Any idea how to do that? As the i resp. r constraints are
> used on the MEM operand, the match_operand cannot be easily extended
> to include the MEM as well.
> I've tried to play with
> (match_operator:SI 2 "memory_operand"
>  [(match_operand:DI 0 "x86_64_movabs_operand" "i,r,r")])
> but this does not seem to work, likely because of the hidden
> MEM arguments.
> Do you think x86_64_movabs_operand should include the MEM and
> add new constraints for MEM with immediate operand or register operand,
> or should movabs* use TARGET_64BIT && nonvolatile_mem_insn (insn)
> where nonvolatile_mem_insn would find the MEM around the operand and check
> it for memory_operand?

In the case you will be adding new constraints (which is ineed the
cleanest choice), it would be nice to merge them into the ordinary mov
patterns too.

Honza
> 
> 	Jakub


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