> From: Georg-Johann Lay
> To: Jamie Prescott
> Cc: Eric Botcazou ; gcc@gcc.gnu.org; Jim Wilson
> ; Ian Lance Taylor
> Sent: Wednesday, May 27, 2009 12:11:08 PM
> Subject: Re: Seeking suggestion
>
> Jamie Prescott schrieb:
>
> >>> Thanks for the ex
Jamie Prescott schrieb:
Thanks for the explanation. I somehow thought that every insn spit out by a
define_insn was automatically turned into a parallel.
That's true, the template of a define_insn is automatically wrapped up in a
PARALLEL. But your addsi3 is a define_expand and this works di
> From: Eric Botcazou
> To: Jamie Prescott
> Cc: gcc@gcc.gnu.org; Jim Wilson ; Georg-Johann Lay
> ; Ian Lance Taylor
> Sent: Wednesday, May 27, 2009 10:37:24 AM
> Subject: Re: Seeking suggestion
>
> > Thanks for the explanation. I somehow thought that every insn sp
> Thanks for the explanation. I somehow thought that every insn spit out by a
> define_insn was automatically turned into a parallel.
That's true, the template of a define_insn is automatically wrapped up in a
PARALLEL. But your addsi3 is a define_expand and this works differently.
--
Eric Bot
> From: Jamie Prescott
> To: Jim Wilson
> Cc: Georg-Johann Lay ; Ian Lance Taylor ;
> gcc@gcc.gnu.org
> Sent: Wednesday, May 27, 2009 10:12:42 AM
> Subject: Re: Seeking suggestion
>
> Thanks for the explanation. I somehow thought that every insn spit out by a
> defi
> From: Jim Wilson
> To: Jamie Prescott
> Cc: Georg-Johann Lay ; Ian Lance Taylor ;
> gcc@gcc.gnu.org
> Sent: Tuesday, May 26, 2009 7:47:45 PM
> Subject: Re: Seeking suggestion
>
> Jamie Prescott wrote:
> > Is there a reason why something like this would not
Jamie Prescott wrote:
Is there a reason why something like this would not work?
if (!TARGET_XXX2)
emit_clobber(gen_rtx_REG(CCmode, CC_REGNUM));
emit_insn(gen_addsi3_nc(operands[0], operands[1], operands[2]));
Yes. The optimizer will not know that addsi3_nc uses CC_REGNUM, as it
> From: Michael Meissner
> To: Jamie Prescott
> Cc: gcc@gcc.gnu.org
> Sent: Sunday, May 24, 2009 1:57:19 PM
> Subject: Re: Seeking suggestion
>
> One way is to use match_scratch, and different register classes for the two
> cases.
>
> (define_insn "
On Fri, May 22, 2009 at 05:04:22PM -0700, Jamie Prescott wrote:
>
> > From: Jamie Prescott
> > To: gcc@gcc.gnu.org
> > Sent: Friday, May 22, 2009 10:36:47 AM
> > Subject: Seeking suggestion
> >
> >
> > Suppose you're writing the backend for a VM supporting two architectures,
> > in
> > which
Jamie Prescott schrieb:
Is there a reason why something like this would not work?
(define_insn "addsi3_nc"
[(set (match_operand:SI 0 "fullreg_operand" "=r")
(plus:SI (match_operand:SI 1 "fullreg_operand" "r")
(match_operand:SI 2 "fullreg_or_imm_operand" "rn")))]
""
> From: Georg-Johann Lay
> To: Jamie Prescott
> Cc: Ian Lance Taylor ; gcc@gcc.gnu.org
> Sent: Saturday, May 23, 2009 12:05:09 AM
> Subject: Re: Seeking suggestion
>
> Jamie Prescott schrieb:
>
> > Is the implementation I posted the only one, or there are shor
Jamie Prescott schrieb:
Is the implementation I posted the only one, or there are shorter/better ones?
You could use insn attribute to express insns' effects on cc_status.
Have a look at the avr backend.
Georg-Johann
> From: Ian Lance Taylor
> To: Jamie Prescott
> Cc: gcc@gcc.gnu.org
> Sent: Friday, May 22, 2009 5:45:21 PM
> Subject: Re: Seeking suggestion
>
> Jamie Prescott writes:
>
> > But now I get and invalid rtx sharing from the push/pop parallels:
>
> This nor
Jamie Prescott writes:
> But now I get and invalid rtx sharing from the push/pop parallels:
This normally means that you need a copy_rtx somewhere. Different insns
may not share data structure.
Ian
> From: Jamie Prescott
> To: gcc@gcc.gnu.org
> Sent: Friday, May 22, 2009 10:36:47 AM
> Subject: Seeking suggestion
>
>
> Suppose you're writing the backend for a VM supporting two architectures, in
> which
> one of them clobbers the CC registers for certain instructions, while the
> other
>
15 matches
Mail list logo
