On Wed, 8 Jan 2014, Kugan wrote:
>
> On 07/01/14 23:23, Richard Biener wrote:
> > On Tue, 7 Jan 2014, Kugan wrote:
>
> [snip]
>
>
> > Note that VIEW_CONVERT_EXPR is wrong here. I think you are
> > handling this wrong still. From a quick look you want to avoid
> > the actual promotion for
> >
On 07/01/14 23:23, Richard Biener wrote:
> On Tue, 7 Jan 2014, Kugan wrote:
[snip]
> Note that VIEW_CONVERT_EXPR is wrong here. I think you are
> handling this wrong still. From a quick look you want to avoid
> the actual promotion for
>
> reg_1 =
>
> when reg_1 is promoted and thus
On Tue, 7 Jan 2014, Kugan wrote:
> ping ?
>
> I have reorganised the last patch and now handling only
> VIEW_CONVERT_EXPR, CONVERT_EXPR and NOP_EXPR. Once it is reviewed and
> necessary changes are made, I will address the other cases as a separate
> patch (when it reaches that stage).
Note that
ping ?
I have reorganised the last patch and now handling only
VIEW_CONVERT_EXPR, CONVERT_EXPR and NOP_EXPR. Once it is reviewed and
necessary changes are made, I will address the other cases as a separate
patch (when it reaches that stage).
Thanks,
Kugan
gcc/
+2014-01-07 Kugan Vivekanandaraja
tem = (char) 255 + (char) 1;
>>
>> tem is always of type 'char' in GIMPLE (even if later promoted
>> via PROMOTE_MODE) the value-range is a 'char' value-range and thus
>> never will exceed [CHAR_MIN, CHAR_MAX]. The only way you can
>> use that directly is if you can rely on undefined behav
>>> tem = (char) 255 + (char) 1;
>>>
>>> which has a value-range of [0,0] but clearly when computed in
>>> SImode the value-range is [256, 256]. That is, VRP computes
>>> value-ranges in the expression type, not in some arbitrary
>>> larger type.
>>>
>>> So what you'd have to do is take the val
On Wed, 16 Oct 2013, Kugan wrote:
> Thanks Richard for the review.
>
> On 15/10/13 23:55, Richard Biener wrote:
> > On Tue, 15 Oct 2013, Kugan wrote:
> >
> >> Hi Eric,
> >>
> >> Can you please help to review this patch?
> >> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00452.html
> >
> > I thin
Thanks Richard for the review.
On 15/10/13 23:55, Richard Biener wrote:
> On Tue, 15 Oct 2013, Kugan wrote:
>
>> Hi Eric,
>>
>> Can you please help to review this patch?
>> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00452.html
>
> I think that gimple_assign_is_zero_sign_ext_redundant and its
>
On Tue, 15 Oct 2013, Kugan wrote:
> Hi Eric,
>
> Can you please help to review this patch?
> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00452.html
I think that gimple_assign_is_zero_sign_ext_redundant and its
description is somewhat confused. You seem to have two cases
here, one being NOP_EXP
Hi Eric,
Can you please help to review this patch?
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00452.html
Thanks,
Kugan
> +2013-09-25 Kugan Vivekanandarajah
> +
> + * dojump.c (do_compare_and_jump): Generate rtl without
> + zero/sign extension if redundant.
> + * cfgexpand.c (exp
Ping~
Thanks,
Kugan
+2013-09-25 Kugan Vivekanandarajah
+
+ * dojump.c (do_compare_and_jump): Generate rtl without
+ zero/sign extension if redundant.
+ * cfgexpand.c (expand_gimple_stmt_1): Likewise.
+ * gimple.c (gimple_assign_is_zero_sign_ext_redundant) : New
+
Hi,
This is the updated patch for expanding gimple stmts without zer/sign
extensions when it is safe to do that. This is based on the
latest changes to propagating value range information to SSA_NAMEs
and addresses review comments from Eric.
Bootstrapped and regtested on x86_64-unknown-linux-gnu
I'd like to ping this patch 2 of 2 that removes redundant zero/sign
extension using value range information.
Bootstrapped and no new regression for x86_64-unknown-linux-gnu and
arm-none-linux-gnueabi.
Thanks you for your time.
Kugan
On 14/08/13 16:59, Kugan wrote:
Hi Eric,
Thanks for rev
Hi Eric,
Thanks for reviewing the patch.
On 01/07/13 18:51, Eric Botcazou wrote:
[Sorry for the delay]
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)
[Sorry for the delay]
> 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
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
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 exte
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 conver
18 matches
Mail list logo
