Since this came up the other day in the "post-reload compare
optimization pass" discussion, I thought better comment on
this old post in case someone is tempted to do something...
On Wed, 2 Nov 2011, Richard Henderson wrote:
> Frankly, I'd prefer to flip the default. It does seem to make the most
On 11/01/2011 02:59 PM, Hans-Peter Nilsson wrote:
> Please, when replying, also send to me, not just the list.
>
> On Tue, 1 Nov 2011, Paulo J. Matos wrote:
>> On 01/11/11 02:43, Hans-Peter Nilsson wrote:
>>>
>>> Not obvious or maybe I was unclear as to what I alluded?
>>> In the below insn-bodies
Please, when replying, also send to me, not just the list.
On Tue, 1 Nov 2011, Paulo J. Matos wrote:
> On 01/11/11 02:43, Hans-Peter Nilsson wrote:
> >
> > Not obvious or maybe I was unclear as to what I alluded?
> > In the below insn-bodies, "sub" is the insn that sets cc0 as a
> > side-effect.
>
On 01/11/11 02:43, Hans-Peter Nilsson wrote:
Not obvious or maybe I was unclear as to what I alluded?
In the below insn-bodies, "sub" is the insn that sets cc0 as a
side-effect.
Supposed canonical form :
(parallel
[(set cc_reg) (compare ...))
(set destreg) (sub ...))])
and:
(parallel
[(
On Mon, 31 Oct 2011, Paulo J. Matos wrote:
> On 31/10/11 05:36, Hans-Peter Nilsson wrote:
> > BTW, I
> > don't think it helps that someone decided the canonical form of
> > a parallel that includes a CC-setter must have the CC-setting
> > *first* (contrasting with the position of clobbers)...
>
> H
Quoting Hans-Peter Nilsson :
I came to the somewhat the same conclusion for CRIS where all
insns set condition codes except move to memory and a "add
reg1,reg2" (no immediate operand) and to/from special registers:
there'll one clobbering and one CC_REG-setting pattern plus a
load of others (pee
On 31/10/11 05:36, Hans-Peter Nilsson wrote:
BTW, I
don't think it helps that someone decided the canonical form of
a parallel that includes a CC-setter must have the CC-setting
*first* (contrasting with the position of clobbers)...
How did you reach this conclusion?
--
PMatos
On 29/10/11 18:33, Peter Bigot wrote:
On Sat, Oct 29, 2011 at 10:58 AM, Richard Henderson wrote:
On 10/29/2011 05:41 AM, Peter Bigot wrote:
It seems cc0 should probably still be preferred for CISC-style
architectures like the MSP430. I'll give that approach a try.
I think that's somewhat un
On 28/10/11 17:59, Richard Henderson wrote:
On 10/28/2011 06:49 AM, Peter Bigot wrote:
I'm inclined to follow sparc's lead, but is one or another of the choices
more likely to help combine/reload/etc do a better job?
I don't know.
In the case of RX, we don't model CC_REG until after reload, s
On Sat, 29 Oct 2011, Peter Bigot wrote:
> On Fri, Oct 28, 2011 at 11:59 AM, Richard Henderson wrote:
> Based on what I've encountered so far, between having to duplicate many
> insns (one with CC_REG, one without), adding splits to convert between them,
> and making a hash of the templates for the
On Sat, Oct 29, 2011 at 10:58 AM, Richard Henderson wrote:
> On 10/29/2011 05:41 AM, Peter Bigot wrote:
>> It seems cc0 should probably still be preferred for CISC-style
>> architectures like the MSP430. I'll give that approach a try.
>
> I think that's somewhat unfair. Take a close look at the
On 10/29/2011 05:41 AM, Peter Bigot wrote:
> It seems cc0 should probably still be preferred for CISC-style
> architectures like the MSP430. I'll give that approach a try.
I think that's somewhat unfair. Take a close look at the RX and
mn10300 ports -- they're what I would call the most up-to-da
On Fri, Oct 28, 2011 at 11:59 AM, Richard Henderson wrote:
> On 10/28/2011 06:49 AM, Peter Bigot wrote:
>> I'm inclined to follow sparc's lead, but is one or another of the choices
>> more likely to help combine/reload/etc do a better job?
>
> I don't know.
>
> In the case of RX, we don't model CC
On 10/28/2011 06:49 AM, Peter Bigot wrote:
> I'm inclined to follow sparc's lead, but is one or another of the choices
> more likely to help combine/reload/etc do a better job?
I don't know.
In the case of RX, we don't model CC_REG until after reload, so combine really
doesn't get a shot at it.
I'm rewriting a back-end originally based on AVR to eliminate insns for
multi-word operations (output templates like "add\;addc") and to use MODE_CC
instead of an unusual attribute-based approach. The motivation is that I've
mostly found gcc does a better job than the existing back-end if it's sho
15 matches
Mail list logo
