This is the mail archive of the gcc@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: Postreload and STRICT_LOW_PART

From: Paolo Bonzini <bonzini at gnu dot org>
To: Richard Guenther <richard dot guenther at gmail dot com>
Cc: Andreas Schwab <schwab at linux-m68k dot org>, gcc at gcc dot gnu dot org
Date: Sun, 20 Sep 2009 19:25:00 +0200
Subject: Re: Postreload and STRICT_LOW_PART
References: <m27hvtbnrf.fsf@igel.home> <84fc9c000909200931o948744en1ce0e2403e0e58c6@mail.gmail.com>

On 09/20/2009 06:31 PM, Richard Guenther wrote:

On Sun, Sep 20, 2009 at 6:10 PM, Andreas Schwab<schwab@linux-m68k.org> wrote:

Why is postreload converting (set (REGX) (CONST_INT A)) ... (set (REGX)
(CONST_INT B)) into (set (STRICT_LOW_PART (REGX)) (CONST_INT B))?  That
looks like a pessimisation especially if the constants are small, since
STRICT_LOW_PART must not touch the high part.  Is there a way for the
backend to stop postreload from doing this if the constants are in some
range?  On the m68k, loading a constant in the range -128..127 in SI
mode is better than loading it in strict QI mode.


It's probably an omission of a check if A&  ~GET_MODE_MASK (narrow_mode)
is equal to zero.

Actually it is (A^B) & ~GET_MODE_MASK(narrow_mode) that has to be 0.

And of course a cost check is completely missing.

I think that adding a cost check would be the right thing to do. For size, a QImode move is probably better (it is on i386 for example).

Paolo

References:
- Postreload and STRICT_LOW_PART
  - From: Andreas Schwab
- Re: Postreload and STRICT_LOW_PART
  - From: Richard Guenther

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