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: Canonicalization of compares performed as side-effect operations

From: Eric Botcazou <ebotcazou at adacore dot com>
To: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
Cc: gcc-patches at gcc dot gnu dot org, Segher Boessenkool <segher at kernel dot crashing dot org>
Date: Tue, 06 Aug 2019 19:30:45 +0200
Subject: Re: Canonicalization of compares performed as side-effect operations
References: <bc94810b-140c-71d4-eca5-9e2c6efae2f7@arm.com> <20190806163915.GR31406@gate.crashing.org> <d82c7824-1183-ed1e-a44a-2e5cf10e878d@arm.com>

> Why is it incorrect?  It's not canonical, sure.  But the cannonical form
> does NOT describe what the instruction does.

Yes, you run into this when you try to be clever with the carry.  For the 
Visium port I kludged around it by using:

  [(set (reg:CCC R_FLAGS)
	(compare:CCC (not:I (match_operand:I 0 "register_operand" "r"))
		     (const_int -1)))]

and recognizing the -1 in SELECT_CC_MODE.  Obviously cumbersome though.

-- 
Eric Botcazou

Follow-Ups:
- Re: Canonicalization of compares performed as side-effect operations
  - From: Richard Earnshaw (lists)

References:
- Canonicalization of compares performed as side-effect operations
  - From: Richard Earnshaw (lists)
- Re: Canonicalization of compares performed as side-effect operations
  - From: Segher Boessenkool
- Re: Canonicalization of compares performed as side-effect operations
  - From: Richard Earnshaw (lists)

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