public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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.
>> +
>>
>>
>>
>>
>>
>>
>>
>

  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).