On 08/09/14 19:48, Richard Biener wrote:
On Sun, Sep 7, 2014 at 11:50 AM, Kugan
kugan.vivekanandara...@linaro.org 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
On Tue, Sep 9, 2014 at 12:06 PM, Kugan
kugan.vivekanandara...@linaro.org wrote:
On 08/09/14 19:48, Richard Biener wrote:
On Sun, Sep 7, 2014 at 11:50 AM, Kugan
kugan.vivekanandara...@linaro.org wrote:
On 05/09/14 19:50, Richard Biener wrote:
Well - the best way would be to expose the
On Sun, Sep 7, 2014 at 11:50 AM, Kugan
kugan.vivekanandara...@linaro.org 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
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, have a
On Fri, Sep 5, 2014 at 3:33 AM, Kugan kugan.vivekanandara...@linaro.org 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
On Thu, Sep 4, 2014 at 5:41 AM, Kugan kugan.vivekanandara...@linaro.org 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
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.
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
convert_move
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)
+++
On Mon, Sep 1, 2014 at 10:47 AM, Jakub Jelinek ja...@redhat.com 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 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 kug...@linaro.org
* calls.c (precompute_arguments): Check
promoted_for_signed_and_unsigned_p and set the promoted mode.
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 kug...@linaro.org
* calls.c (precompute_arguments): Check
promoted_for_signed_and_unsigned_p and set
On 27/08/14 20:07, Richard Biener wrote:
On Wed, Aug 27, 2014 at 12:01 PM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
2014-08-07 Kugan Vivekanandarajah kug...@linaro.org
* calls.c (precompute_arguments): Check
promoted_for_signed_and_unsigned_p and set the promoted mode.
On Thu, Aug 28, 2014 at 9:50 AM, Kugan
kugan.vivekanandara...@linaro.org wrote:
On 27/08/14 20:07, Richard Biener wrote:
On Wed, Aug 27, 2014 at 12:01 PM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
2014-08-07 Kugan Vivekanandarajah kug...@linaro.org
* calls.c (precompute_arguments):
Hello!
2014-08-07 Kugan Vivekanandarajah kug...@linaro.org
* 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
On Wed, Aug 27, 2014 at 12:01 PM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
2014-08-07 Kugan Vivekanandarajah kug...@linaro.org
* 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 Wed, Aug 27, 2014 at 12:25 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, Aug 27, 2014 at 12:07 PM, Richard Biener
richard.guent...@gmail.com wrote:
2014-08-07 Kugan Vivekanandarajah kug...@linaro.org
* calls.c (precompute_arguments): Check
promoted_for_signed_and_unsigned_p and set
On Wed, Aug 27, 2014 at 12:07 PM, Richard Biener
richard.guent...@gmail.com wrote:
2014-08-07 Kugan Vivekanandarajah kug...@linaro.org
* 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 kug...@linaro.org
* 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 27/08/14 23:02, Kugan wrote:
On 27/08/14 20:01, Uros Bizjak wrote:
Hello!
2014-08-07 Kugan Vivekanandarajah kug...@linaro.org
* 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 Tue, Aug 5, 2014 at 4:21 PM, Jakub Jelinek ja...@redhat.com 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:PROMOTE_MODE of ssa N))?
On 06/08/14 22:09, Richard Biener wrote:
On Tue, Aug 5, 2014 at 4:21 PM, Jakub Jelinek ja...@redhat.com 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
On Wed, Aug 6, 2014 at 3:21 PM, Kugan kugan.vivekanandara...@linaro.org wrote:
On 06/08/14 22:09, Richard Biener wrote:
On Tue, Aug 5, 2014 at 4:21 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Aug 05, 2014 at 04:17:41PM +0200, Richard Biener wrote:
what's the semantic of setting
On 06/08/14 23:29, Richard Biener wrote:
On Wed, Aug 6, 2014 at 3:21 PM, Kugan kugan.vivekanandara...@linaro.org
wrote:
On 06/08/14 22:09, Richard Biener wrote:
On Tue, Aug 5, 2014 at 4:21 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Aug 05, 2014 at 04:17:41PM +0200, Richard Biener
On Fri, Aug 1, 2014 at 6:03 PM, Kugan kugan.vivekanandara...@linaro.org 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 =
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:PROMOTE_MODE of ssa N))?
SRP_SIGNED_AND_UNSIGNED on a subreg should mean that
the subreg is both zero and sign
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
need sign-extension
I
On Fri, Aug 1, 2014 at 6:51 AM, Kugan kugan.vivekanandara...@linaro.org 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,
+
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 we will have to check that
+ 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::from
On Mon, Jul 14, 2014 at 4:57 AM, Kugan
kugan.vivekanandara...@linaro.org wrote:
On 11/07/14 22:47, Richard Biener wrote:
On Fri, Jul 11, 2014 at 1:52 PM, Kugan
kugan.vivekanandara...@linaro.org wrote:
Thanks foe the review and suggestions.
On 10/07/14 22:15, Richard Biener wrote:
On Mon,
On 14 July 2014 04:58:17 Kugan kugan.vivekanandara...@linaro.org wrote:
On 11/07/14 22:47, Richard Biener wrote:
On Fri, Jul 11, 2014 at 1:52 PM, Kugan
kugan.vivekanandara...@linaro.org wrote:
Thanks foe the review and suggestions.
On 10/07/14 22:15, Richard Biener wrote:
On Mon, Jul 7,
On 11/07/14 22:47, Richard Biener wrote:
On Fri, Jul 11, 2014 at 1:52 PM, Kugan
kugan.vivekanandara...@linaro.org 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 kugan.vivekanandara...@linaro.org
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 kugan.vivekanandara...@linaro.org
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
On Fri, Jul 11, 2014 at 1:52 PM, Kugan
kugan.vivekanandara...@linaro.org 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 kugan.vivekanandara...@linaro.org
wrote:
[...]
For -fwrapv, it is due to how PROMOTE_MODE
On Mon, Jul 7, 2014 at 8:55 AM, Kugan kugan.vivekanandara...@linaro.org 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
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 loop is
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 kug...@linaro.org
* gcc/calls.c (precompute_arguments: Check is_promoted_for_type
and set the promoted mode.
(is_promoted_for_type) : New
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++)
;
}
-Os
On Tue, Jun 24, 2014 at 09:53:35PM +1000, Kugan wrote:
2014-06-24 Kugan Vivekanandarajah kug...@linaro.org
* 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
40 matches
Mail list logo
