From: Richard Biener <richard.guenther@gmail.com>
To: Jim Wilson <jim.wilson@linaro.org>,Richard Earnshaw
<Richard.Earnshaw@foss.arm.com>
Cc: Michael Matz <matz@suse.de>,Jeff Law
<law@redhat.com>,"gcc-patches@gcc.gnu.org"
<gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH, ARM] stop changing signedness in PROMOTE_MODE
Date: Tue, 14 Jul 2015 17:23:00 -0000 [thread overview]
Message-ID: <2A988B5F-CD6E-44EB-8198-835420DF24D1@gmail.com> (raw)
In-Reply-To: <CABXYE2VKvB70mvYTrV5fgH4z+h4+G0cFM8Q+X-UL=aCb+-ZPFA@mail.gmail.com>
On July 14, 2015 6:49:18 PM GMT+02:00, Jim Wilson <jim.wilson@linaro.org> wrote:
>On Tue, Jul 14, 2015 at 9:13 AM, Richard Earnshaw
><Richard.Earnshaw@foss.arm.com> wrote:
>> We went through this a couple of weeks back. The backend
>documentation
>> for PROMOTE_MODE says:
>
>I disagree that this is a fully resolved issue. I see clear problems
>with how the ARM port uses PROMOTE_MODE.
>
>> " For most machines, the macro definition does not change
>@var{unsignedp}.
>> However, some machines, have instructions that preferentially handle
>> either signed or unsigned quantities of certain modes. For example,
>on
>> the DEC Alpha, 32-bit loads from memory and 32-bit add instructions
>> sign-extend the result to 64 bits. On such machines, set
>> @var{unsignedp} according to which kind of extension is more
>efficient."
>
>The Alpha case is different than the ARM case. The Alpha only changes
>sign for 32-bit values in 64-bit registers. The alpha happens to have
>a nice set of instructions that operates on 32-bit values, that
>accepts these wrong-signed values and handle them correctly. Thus on
>the alpha, it appears that there are no extra zero/sign extends
>required, and everything is the same speed or faster with the wrong
>sign. The MIPS port works the same way. This is not true on the arm
>though. The arm port is changing sign on 8 and 16 bit value, but does
>not have instructions that directly operate on 8 and 16 bit values.
>This requires the compiler to emit extra zero/sign extend instructions
>that affect the performance of the code. Other than the thumb1 8-bit
>load, and the pre-armv6 use of andi for 8-bit zero-extend, I haven't
>seen anything that is faster in the wrong sign, and there are a number
>of operations that are actually slower because of the extra zero/sign
>extends required by the arm PROMOTE_MODE definition. I've given some
>examples.
>
>I have since noticed that the relatively new pass to optimize away
>unnecessary zero/sign extensions is actually fixing some of the damage
>caused by the ARM PROMOTE_MODE definition. But there are still some
>cases that won't get fixed, as per my earlier examples. It is better
>to emit the fast code at the beginning than to rely on an optimization
>pass to convert the slow code into fast code. So I think the ARM
>PROMOTE_MODE definition still needs to be fixed.
>
>> So clearly it anticipates that all permitted extensions should work,
>and
>> in particular it makes no mention of this having to match some
>> abi-mandated promotions. That makes this a MI bug not a target one.
>
>If you look at older gcc releases, like gcc-2.95.3, you will see that
>there is only PROMOTE_MODE and a boolean PROMOTE_FUNCTION_ARGS which
>says whether PROMOTE_MODE is applied to function arguments or not.
>You can't have different zero/sign extensions for parameters and
>locals in gcc-2.95.3. The fact that you can have it today is more an
>accident than a deliberate choice. When PROMOTE_FUNCTION_ARGS was
>hookized, it was made into a separate function, and for the ARM port,
>the code for PROMOTE_MODE was not correctly copied into the new hook,
>resulting in the accidental difference for parameter and local
>zero/sign promotion for ARM. The PROMOTE_MODE docs were written back
>when different sign/zero extensions for parms/locals weren't possible,
>and hence did not consider the case.
>
>Now that we do have the problem, we can't fix it without an ARM port
>ABI change, which is undesirable, so we may have to fix it with a MI
>change.
>
>There were two MI changes suggested, one was fixing the out-of-ssa
>pass to handle SUBREG_PROMOTED_P promotions. The other was to
>disallow creating PHI nodes between parms and locals. I haven't had a
>chance to try implementing the second one yet; I hope to work on that
>today.
I will definitely veto such restriction.
Richard.
>Jim
next prev parent reply other threads:[~2015-07-14 17:21 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-30 1:56 Jim Wilson
2015-07-02 9:07 ` Richard Earnshaw
2015-07-07 18:25 ` Jim Wilson
2015-07-07 15:07 ` Jeff Law
2015-07-07 16:29 ` Jim Wilson
2015-07-07 21:35 ` Richard Biener
2015-07-10 15:46 ` Jim Wilson
2015-07-13 8:19 ` Richard Biener
2015-07-13 15:29 ` Michael Matz
2015-07-13 15:35 ` H.J. Lu
2015-07-14 16:38 ` Richard Earnshaw
2015-07-14 16:49 ` Richard Biener
2015-07-14 17:07 ` Jim Wilson
2015-07-14 17:23 ` Richard Biener [this message]
2015-07-15 13:25 ` Michael Matz
2015-07-15 16:01 ` Jim Wilson
2015-07-16 9:40 ` Richard Earnshaw
2015-07-16 15:02 ` Michael Matz
2015-07-16 15:20 ` Richard Earnshaw
2015-07-15 13:04 ` Michael Matz
2015-07-08 22:54 ` Jeff Law
2015-07-10 15:35 ` Jim Wilson
2016-02-04 8:58 ` Ramana Radhakrishnan
2016-02-15 11:32 ` Kyrill Tkachov
2016-02-16 10:44 ` Ramana Radhakrishnan
2016-02-17 10:03 ` Christophe Lyon
2016-02-17 10:05 ` Kyrill Tkachov
2016-02-17 10:20 ` Christophe Lyon
2016-02-17 10:22 ` Kyrill Tkachov
2016-02-18 10:16 ` Christophe Lyon
2016-03-07 4:43 ` Ramana Radhakrishnan
2016-03-07 12:55 ` Christophe Lyon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2A988B5F-CD6E-44EB-8198-835420DF24D1@gmail.com \
--to=richard.guenther@gmail.com \
--cc=Richard.Earnshaw@foss.arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jim.wilson@linaro.org \
--cc=law@redhat.com \
--cc=matz@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).