On Tue, Sep 9, 2014 at 12:06 PM, Kugan
wrote:
>
>
> On 08/09/14 19:48, Richard Biener wrote:
>> On Sun, Sep 7, 2014 at 11:50 AM, Kugan
>> wrote:
>>> On 05/09/14 19:50, Richard Biener wrote:
>>>
Well - the best way would be to expose the target specifics to GIMPLE
at some point in the op
On 08/09/14 19:48, Richard Biener wrote:
> On Sun, Sep 7, 2014 at 11:50 AM, Kugan
> wrote:
>> On 05/09/14 19:50, Richard Biener wrote:
>>
>>> Well - the best way would be to expose the target specifics to GIMPLE
>>> at some point in the optimization pipeline. My guess would be that it's
>>> app
On Sun, Sep 7, 2014 at 11:50 AM, Kugan
wrote:
> On 05/09/14 19:50, Richard Biener wrote:
>
>> Well - the best way would be to expose the target specifics to GIMPLE
>> at some point in the optimization pipeline. My guess would be that it's
>> appropriate after loop optimizations (but maybe before
On 05/09/14 19:50, Richard Biener wrote:
> Well - the best way would be to expose the target specifics to GIMPLE
> at some point in the optimization pipeline. My guess would be that it's
> appropriate after loop optimizations (but maybe before induction variable
> optimization).
>
> That is, hav
On Fri, Sep 5, 2014 at 3:33 AM, Kugan wrote:
>>> Here is an attempt to do the value range computation in promoted_mode's
>>> type when it is overflowing. Bootstrapped on x86-84.
>>
>> Err - I think you misunderstood this as a suggestion to do this ;)
>> value-ranges should be computed according to
>> Here is an attempt to do the value range computation in promoted_mode's
>> type when it is overflowing. Bootstrapped on x86-84.
>
> Err - I think you misunderstood this as a suggestion to do this ;)
> value-ranges should be computed according to the type not according
> to the (promoted) mode.
On Thu, Sep 4, 2014 at 5:41 AM, Kugan wrote:
>>> I added this part of the code (in cfgexpand.c) to handle binary/unary/..
>>> gimple operations and used the LHS value range to infer the assigned
>>> value range. I will revert this part of the code as this is wrong.
>>>
>>> I dont think checking pr
>> I added this part of the code (in cfgexpand.c) to handle binary/unary/..
>> gimple operations and used the LHS value range to infer the assigned
>> value range. I will revert this part of the code as this is wrong.
>>
>> I dont think checking promoted_mode for temp will be necessary here as
>> c
On Mon, Sep 1, 2014 at 10:47 AM, Jakub Jelinek wrote:
> On Wed, Aug 27, 2014 at 12:25:14PM +0200, Uros Bizjak wrote:
>> Something like following (untested) patch that also fixes the testcase
>> perhaps?
>>
>> -- cut here--
>> Index: cfgexpand.c
>> =
On Wed, Aug 27, 2014 at 12:25:14PM +0200, Uros Bizjak wrote:
> Something like following (untested) patch that also fixes the testcase
> perhaps?
>
> -- cut here--
> Index: cfgexpand.c
> ===
> --- cfgexpand.c (revision 214445)
> +++ c
On Thu, Aug 28, 2014 at 9:50 AM, Kugan
wrote:
>
>
> On 27/08/14 20:07, Richard Biener wrote:
>> On Wed, Aug 27, 2014 at 12:01 PM, Uros Bizjak wrote:
>>> Hello!
>>>
2014-08-07 Kugan Vivekanandarajah
* calls.c (precompute_arguments): Check
promoted_for_signed_and_unsigned_p a
On 27/08/14 20:07, Richard Biener wrote:
> On Wed, Aug 27, 2014 at 12:01 PM, Uros Bizjak wrote:
>> Hello!
>>
>>> 2014-08-07 Kugan Vivekanandarajah
>>>
>>> * calls.c (precompute_arguments): Check
>>> promoted_for_signed_and_unsigned_p and set the promoted mode.
>>> (promoted_for_signed_and_uns
On 28/08/14 16:44, Marc Glisse wrote:
> On Thu, 28 Aug 2014, Kugan wrote:
>
>> On 27/08/14 23:02, Kugan wrote:
>>> On 27/08/14 20:01, Uros Bizjak wrote:
Hello!
> 2014-08-07 Kugan Vivekanandarajah
>
> * calls.c (precompute_arguments): Check
> promoted_for_signed_and_u
On Thu, 28 Aug 2014, Kugan wrote:
On 27/08/14 23:02, Kugan wrote:
On 27/08/14 20:01, Uros Bizjak wrote:
Hello!
2014-08-07 Kugan Vivekanandarajah
* calls.c (precompute_arguments): Check
promoted_for_signed_and_unsigned_p and set the promoted mode.
(promoted_for_signed_and_unsigned_p): New
On 27/08/14 23:02, Kugan wrote:
> On 27/08/14 20:01, Uros Bizjak wrote:
>> Hello!
>>
>>> 2014-08-07 Kugan Vivekanandarajah
>>>
>>> * calls.c (precompute_arguments): Check
>>> promoted_for_signed_and_unsigned_p and set the promoted mode.
>>> (promoted_for_signed_and_unsigned_p): New function.
>>
On 27/08/14 20:01, Uros Bizjak wrote:
> Hello!
>
>> 2014-08-07 Kugan Vivekanandarajah
>>
>> * calls.c (precompute_arguments): Check
>> promoted_for_signed_and_unsigned_p and set the promoted mode.
>> (promoted_for_signed_and_unsigned_p): New function.
>> (expand_expr_real_1): Check promoted_for
On Wed, Aug 27, 2014 at 12:07 PM, Richard Biener
wrote:
>> 2014-08-07 Kugan Vivekanandarajah
>>>
>>> * calls.c (precompute_arguments): Check
>>> promoted_for_signed_and_unsigned_p and set the promoted mode.
>>> (promoted_for_signed_and_unsigned_p): New function.
>>> (expand_expr_real_1): Check
On Wed, Aug 27, 2014 at 12:25 PM, Uros Bizjak wrote:
> On Wed, Aug 27, 2014 at 12:07 PM, Richard Biener
> wrote:
>>> 2014-08-07 Kugan Vivekanandarajah
* calls.c (precompute_arguments): Check
promoted_for_signed_and_unsigned_p and set the promoted mode.
(promoted_for_signed_
On Wed, Aug 27, 2014 at 12:01 PM, Uros Bizjak wrote:
> Hello!
>
>> 2014-08-07 Kugan Vivekanandarajah
>>
>> * calls.c (precompute_arguments): Check
>> promoted_for_signed_and_unsigned_p and set the promoted mode.
>> (promoted_for_signed_and_unsigned_p): New function.
>> (expand_expr_real_1): Che
Hello!
> 2014-08-07 Kugan Vivekanandarajah
>
> * calls.c (precompute_arguments): Check
> promoted_for_signed_and_unsigned_p and set the promoted mode.
> (promoted_for_signed_and_unsigned_p): New function.
> (expand_expr_real_1): Check promoted_for_signed_and_unsigned_p
> and set the promoted mo
On Thu, Aug 7, 2014 at 7:24 AM, Kugan wrote:
> On 06/08/14 23:29, Richard Biener wrote:
>> On Wed, Aug 6, 2014 at 3:21 PM, Kugan
>> wrote:
>>> On 06/08/14 22:09, Richard Biener wrote:
On Tue, Aug 5, 2014 at 4:21 PM, Jakub Jelinek wrote:
> On Tue, Aug 05, 2014 at 04:17:41PM +0200, Richa
On 06/08/14 23:29, Richard Biener wrote:
> On Wed, Aug 6, 2014 at 3:21 PM, Kugan
> wrote:
>> On 06/08/14 22:09, Richard Biener wrote:
>>> On Tue, Aug 5, 2014 at 4:21 PM, Jakub Jelinek wrote:
On Tue, Aug 05, 2014 at 04:17:41PM +0200, Richard Biener wrote:
> what's the semantic of setting
On Wed, Aug 6, 2014 at 3:21 PM, Kugan wrote:
> On 06/08/14 22:09, Richard Biener wrote:
>> On Tue, Aug 5, 2014 at 4:21 PM, Jakub Jelinek wrote:
>>> On Tue, Aug 05, 2014 at 04:17:41PM +0200, Richard Biener wrote:
what's the semantic of setting SRP_SIGNED_AND_UNSIGNED
on the subreg? That
On 06/08/14 22:09, Richard Biener wrote:
> On Tue, Aug 5, 2014 at 4:21 PM, Jakub Jelinek wrote:
>> On Tue, Aug 05, 2014 at 04:17:41PM +0200, Richard Biener wrote:
>>> what's the semantic of setting SRP_SIGNED_AND_UNSIGNED
>>> on the subreg? That is, for the created (subreg:lhs_mode
>>> (reg: N))?
On Tue, Aug 5, 2014 at 4:21 PM, Jakub Jelinek wrote:
> On Tue, Aug 05, 2014 at 04:17:41PM +0200, Richard Biener wrote:
>> what's the semantic of setting SRP_SIGNED_AND_UNSIGNED
>> on the subreg? That is, for the created (subreg:lhs_mode
>> (reg: N))?
>
> SRP_SIGNED_AND_UNSIGNED on a subreg should
On Tue, Aug 05, 2014 at 04:17:41PM +0200, Richard Biener wrote:
> what's the semantic of setting SRP_SIGNED_AND_UNSIGNED
> on the subreg? That is, for the created (subreg:lhs_mode
> (reg: N))?
SRP_SIGNED_AND_UNSIGNED on a subreg should mean that
the subreg is both zero and sign extended, which me
On Fri, Aug 1, 2014 at 6:03 PM, Kugan wrote:
if (rhs_uns)
return wi::ge_p (min, 0); // if min >= 0 then range contains positive
values
else
return wi::le_p (max, wi::max_value (TYPE_PRECISION (TREE_TYPE
(ssa)), SIGNED); // if max <= signed-max-of-type then
On 02/08/14 02:03, Kugan wrote:
if (rhs_uns)
return wi::ge_p (min, 0); // if min >= 0 then range contains positive
values
else
return wi::le_p (max, wi::max_value (TYPE_PRECISION (TREE_TYPE
(ssa)), SIGNED); // if max <= signed-max-of-type then range doesn't
>>> if (rhs_uns)
>>>return wi::ge_p (min, 0); // if min >= 0 then range contains positive
>>> values
>>> else
>>>return wi::le_p (max, wi::max_value (TYPE_PRECISION (TREE_TYPE
>>> (ssa)), SIGNED); // if max <= signed-max-of-type then range doesn't
>>> need sign-extension
>>
>> I think
On Fri, Aug 1, 2014 at 6:51 AM, Kugan wrote:
>> + lhs_type = lang_hooks.types.type_for_mode (lhs_mode, lhs_uns);
>> ...
>> + && ((!lhs_uns && !wi::neg_p (min, TYPE_SIGN (lhs_type)))
>> ...
>> + type_min = wide_int::from (TYPE_MIN_VALUE (lhs_type), prec,
>> +TYPE_
> + lhs_type = lang_hooks.types.type_for_mode (lhs_mode, lhs_uns);
> ...
> + && ((!lhs_uns && !wi::neg_p (min, TYPE_SIGN (lhs_type)))
> ...
> + type_min = wide_int::from (TYPE_MIN_VALUE (lhs_type), prec,
> +TYPE_SIGN (TREE_TYPE (ssa)));
> + type_max = wide_int::f
On Mon, Jul 14, 2014 at 4:57 AM, Kugan
wrote:
> On 11/07/14 22:47, Richard Biener wrote:
>> On Fri, Jul 11, 2014 at 1:52 PM, Kugan
>> wrote:
>>> Thanks foe the review and suggestions.
>>>
>>> On 10/07/14 22:15, Richard Biener wrote:
On Mon, Jul 7, 2014 at 8:55 AM, Kugan
wrote:
>>>
>>>
On 14 July 2014 04:58:17 Kugan wrote:
On 11/07/14 22:47, Richard Biener wrote:
> On Fri, Jul 11, 2014 at 1:52 PM, Kugan
> wrote:
>> Thanks foe the review and suggestions.
>>
>> On 10/07/14 22:15, Richard Biener wrote:
>>> On Mon, Jul 7, 2014 at 8:55 AM, Kugan
wrote:
>>
>> [...]
>>
On 11/07/14 22:47, Richard Biener wrote:
> On Fri, Jul 11, 2014 at 1:52 PM, Kugan
> wrote:
>> Thanks foe the review and suggestions.
>>
>> On 10/07/14 22:15, Richard Biener wrote:
>>> On Mon, Jul 7, 2014 at 8:55 AM, Kugan
>>> wrote:
>>
>> [...]
>>
For -fwrapv, it is due to how PROMOTE_
On Fri, Jul 11, 2014 at 1:52 PM, Kugan
wrote:
> Thanks foe the review and suggestions.
>
> On 10/07/14 22:15, Richard Biener wrote:
>> On Mon, Jul 7, 2014 at 8:55 AM, Kugan
>> wrote:
>
> [...]
>
>>>
>>> For -fwrapv, it is due to how PROMOTE_MODE is defined in arm back-end.
>>> In the test-case,
Thanks foe the review and suggestions.
On 10/07/14 22:15, Richard Biener wrote:
> On Mon, Jul 7, 2014 at 8:55 AM, Kugan
> wrote:
[...]
>>
>> For -fwrapv, it is due to how PROMOTE_MODE is defined in arm back-end.
>> In the test-case, a function (which has signed char return type) returns
>> -1
On Mon, Jul 7, 2014 at 8:55 AM, Kugan wrote:
>> For -fwrapv I don't see why you'd get into trouble ever, the VRP computation
>> should be well aware of the -fwrapv semantics and the value ranges should
>> reflect that.
>>
>> For -fno-strict-overflow, I have no idea since it is very weirdly defined
> For -fwrapv I don't see why you'd get into trouble ever, the VRP computation
> should be well aware of the -fwrapv semantics and the value ranges should
> reflect that.
>
> For -fno-strict-overflow, I have no idea since it is very weirdly defined.
>
> In any case, for your example above, the lo
On Wed, Jun 25, 2014 at 06:14:57PM +1000, Kugan wrote:
> For these flags, value ranges generated are not usable for extension
> eliminations. Therefore, without this some of the test cases in
> regression fails. For example:
>
> short a;
> void
> foo (void)
> {
> for (a = 0; a >= 0; a++)
> ;
On 24/06/14 22:21, Jakub Jelinek wrote:
> On Tue, Jun 24, 2014 at 09:53:35PM +1000, Kugan wrote:
>> 2014-06-24 Kugan Vivekanandarajah
>>
>> * gcc/calls.c (precompute_arguments: Check is_promoted_for_type
>> and set the promoted mode.
>> (is_promoted_for_type) : New function.
>>
On Tue, Jun 24, 2014 at 09:53:35PM +1000, Kugan wrote:
> 2014-06-24 Kugan Vivekanandarajah
>
> * gcc/calls.c (precompute_arguments: Check is_promoted_for_type
> and set the promoted mode.
> (is_promoted_for_type) : New function.
> (expand_expr_real_1) : Check is_promoted
Sets proper flags on the SUBREG based on value
range info and enables elimination of zext/sext when possible.
Thanks,
Kugan
gcc/
2014-06-24 Kugan Vivekanandarajah
* gcc/calls.c (precompute_arguments: Check is_promoted_for_type
and set the promoted mode.
(is_promoted_f
42 matches
Mail list logo
