From: Kugan <kugan.vivekanandarajah@linaro.org>
To: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
ebotcazou@adacore.com
Cc: Richard Biener <rguenther@suse.de>,
rdsandiford@googlemail.com,
Richard Earnshaw <Richard.Earnshaw@arm.com>,
ramana.radhakrishnan@arm.com
Subject: [ping^2][PATCH][2 of 2] RTL expansion for zero sign extension elimination with VRP
Date: Fri, 21 Jun 2013 10:06:00 -0000 [thread overview]
Message-ID: <51C42591.6040804@linaro.org> (raw)
In-Reply-To: <51BE66F9.20609@linaro.org>
Hi Eric,
Can you please help to review the general idea and this patch for zero
sign extension elimination with VRP?
Thanks,
Kugan
On 17/06/13 11:01, Kugan wrote:
> Can you please help to review this patch? Richard reviewed the original
> patch and asked it to be split into two parts. Also, he wanted a review
> from RTL maintainers for the RTL changes.
>
> Thanks,
> Kugan
>
> On 03/06/13 11:46, Kugan wrote:
>> Hi,
>>
>> This patch removes some of the redundant sign/zero extensions using
>> value range information during RTL expansion.
>>
>> When GIMPLE_ASSIGN stmts with LHS type smaller than word is expanded to
>> RTL, if we can prove that RHS expression value can always fit in LHS
>> type and there is no sign conversion, truncation and extension to fit
>> the type is redundant. For a SUBREG_PROMOTED_VAR_P, Subreg and Zero/sign
>> extensions are therefore redundant.
>>
>> For example, when an expression is evaluated and it's value is assigned
>> to variable of type short, the generated RTL would look something like
>> the following.
>>
>> (set (reg:SI 110)
>> (zero_extend:SI (subreg:HI (reg:SI 117) 0)))
>>
>> However, if during value range propagation, if we can say for certain
>> that the value of the expression which is present in register 117 is
>> within the limits of short and there is no sign conversion, we do not
>> need to perform the subreg and zero_extend; instead we can generate the
>> following RTl.
>>
>> (set (reg:SI 110)
>> (reg:SI 117)))
>>
>> Same could be done for other assign statements.
>>
>> This patch is based on the earlier attempt posted in
>> http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00610.html and addresses
>> the review comments of Richard Biener. I am post-processing the
>> expand_expr_real_2 output in expand_gimple_stmt though. Reason for this
>> is that I would like to process all the possible assignment stmts, not
>> just CASE_CONVERT case and/or the REDUCE_BITFIELD.
>>
>> This change along with expansion improve the geomean of spec2k int
>> benchmark with ref by about ~3.5% on an arm chromebook.
>>
>> Tested on X86_64 and ARM.
>>
>> I would like review comments on this.
>>
>> Thanks,
>> Kugan
>>
>>
>> +2013-06-03 Kugan Vivekanandarajah <kuganv@linaro.org>
>> +
>> + * gcc/dojump.c (do_compare_and_jump): generates rtl without
>> + zero/sign extension if redundant.
>> + * gcc/cfgexpand.c (expand_gimple_stmt_1): Likewise.
>> + * gcc/gimple.c (gimple_assign_is_zero_sign_ext_redundant) : New
>> + function.
>> + * gcc/gimple.h (gimple_assign_is_zero_sign_ext_redundant) : New
>> + function definition.
>> +
>>
>>
>>
>>
>>
>>
>>
>
next prev parent reply other threads:[~2013-06-21 10:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-03 2:16 [PATCH][2 " Kugan
2013-06-17 1:31 ` [ping][PATCH][2 " Kugan
2013-06-21 10:06 ` Kugan [this message]
2013-07-01 9:22 ` [PATCH][2 " Eric Botcazou
2013-08-14 7:30 ` Kugan
2013-09-02 9:33 ` Kugan
2013-09-26 9:25 ` Kugan Vivekanandarajah
2013-10-08 7:32 ` Kugan
2013-10-15 10:28 ` [PING^2][PATCH][2 " Kugan
2013-10-15 13:38 ` Richard Biener
2013-10-16 1:47 ` Kugan
2013-10-18 12:40 ` Richard Biener
2013-10-23 7:20 ` Kugan
2013-12-06 4:24 ` Kugan
2014-01-07 11:59 ` Kugan
2014-01-07 12:24 ` Richard Biener
2014-01-08 7:39 ` Kugan
2014-01-08 10:40 ` Richard Biener
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=51C42591.6040804@linaro.org \
--to=kugan.vivekanandarajah@linaro.org \
--cc=Richard.Earnshaw@arm.com \
--cc=ebotcazou@adacore.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=ramana.radhakrishnan@arm.com \
--cc=rdsandiford@googlemail.com \
--cc=rguenther@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).