[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: extendqihi2 and GCC RTL type system
From:       David Edelsohn <dje.gcc () gmail ! com>
Date:       2016-02-22 18:07:50
Message-ID: CAGWvnymEP2i-wNzbHvAvpCdMWZzELoDRigYXDoCSWgXpbc-WnA () mail ! gmail ! com
[Download RAW message or body]

Hi, Jim

On Mon, Feb 22, 2016 at 12:53 PM, Jim Wilson <jim.wilson@linaro.org> wrote:
> On Mon, Feb 22, 2016 at 7:55 AM, David Edelsohn <dje.gcc@gmail.com> wrote:
>> If I remove extendqihi2 (extend:HI pattern) from the PowerPC port,
>> will that cause any problems for the GCC RTL type system or inhibit
>> optimizations?   I see that Alpha and SPARC define extendqihi2, but
>> IA-64 and AArch64 do not, so there is precedent for both approaches.
>
> aarch64 does have an extendqihi2 pattern.  It uses so many iterator
> macros that you can't use grep to look for stuff.  The extendqihi2
> pattern is called <ANY_OPTAB>qihi2.\

Thanks for the response.  I had missed the all-encompassing iterator for qidi2.

> If you have a target with registers larger than HImode, no HImode
> register operations, qi/hi loads set the entire register, and you
> define PROMOTE_MODE to convert all QImode and HImode operations to the
> same larger mode with the same signedness, then I don't think that
> there is any advantage to having an extendqihi2 pattern.  You should
> get the same code with or without it, as a qimode to himode conversion
> is a no-op.  The only difference should be that with an extendqihi2
> pattern you will see some HImode operations in the RTL, without
> extendqihi2 you will see equivalent operations in the promoted mode.
>
> If you are concerned about this, then just try compiling some large
> code base using two compilers, one with extendqihi2 and one without,
> and check to see if there are any code generation differences.

Segher did a quick sniff test on a large code base and found two minor
differences in code generation.  I wanted to check if there was any
more information than anecdotes.

Thanks, David
[prev in list] [next in list] [prev in thread] [next in thread]