> Hmm, won't (uint32_t + uint32_t-CST) doesn't overflow be sufficient
> condition for such transformation?
Yes, in principle this should suffice. What we're actually looking for
is something like a "proper" (or no) overflow, i.e. an overflow in both
min and max of the value range. In
(a + cst1
On Tue, Jan 17, 2017 at 9:48 AM, Richard Biener
wrote:
> On Tue, Jan 10, 2017 at 2:32 PM, Robin Dapp wrote:
>> Perhaps I'm still missing how some cases are handled or not handled,
>> sorry for the noise.
>>
>>> I'm not sure there is anything to "interpret" -- the operation is unsigned
>>> and ove
ping.
I skimmed through the code to see where transformation like
(a - 1) -> (a + UINT_MAX) are performed. It seems there are only two
places, match.pd (/* A - B -> A + (-B) if B is easily negatable. */)
and fold-const.c.
In order to be able to reliably know whether to zero-extend or to
sign-extend the
On Tue, Jan 10, 2017 at 2:32 PM, Robin Dapp wrote:
> Perhaps I'm still missing how some cases are handled or not handled,
> sorry for the noise.
>
>> I'm not sure there is anything to "interpret" -- the operation is unsigned
>> and overflow is when the operation may wrap around zero. There might
Ping.
To put it shortly, I'm not sure how to differentiate between:
example range of a: [3,3]
(ulong)(a + UINT_MAX) + 1 --> (ulong)(a) + (ulong)(-1 + 1), sign extend
example range of a: [0,0]
(ulong)(a + UINT_MAX) + 1 --> (ulong)(a) + (ulong)(UINT_MAX + 1), no
sign extend
In this case, there is
Perhaps I'm still missing how some cases are handled or not handled,
sorry for the noise.
> I'm not sure there is anything to "interpret" -- the operation is unsigned
> and overflow is when the operation may wrap around zero. There might
> be clever ways of re-writing the expression to
> (uint64_
On Wed, Dec 7, 2016 at 5:14 PM, Robin Dapp wrote:
>> So we have (uint64_t)(uint32 + -1U) + 1 and using TYPE_SIGN (inner_type)
>> produces (uint64_t)uint32 + -1U + 1. This simply means that we cannot ignore
>> overflow of the inner operation and for some reason your change
>> to extract_range_from
> So we have (uint64_t)(uint32 + -1U) + 1 and using TYPE_SIGN (inner_type)
> produces (uint64_t)uint32 + -1U + 1. This simply means that we cannot ignore
> overflow of the inner operation and for some reason your change
> to extract_range_from_binary_expr didn't catch this. That is _8 + 429496729
On Mon, Nov 28, 2016 at 2:26 PM, Robin Dapp wrote:
>>> + /* Sign-extend @1 to TYPE. */
>>> + w1 = w1.from (w1, TYPE_PRECISION (type), SIGNED);
>>>
>>> not sure why you do always sign-extend. If the inner op is unsigned
>>> and we widen then that's certainly bogus consider
Ping. Any idea how to tackle this?
>> + /* Sign-extend @1 to TYPE. */
>> + w1 = w1.from (w1, TYPE_PRECISION (type), SIGNED);
>>
>> not sure why you do always sign-extend. If the inner op is unsigned
>> and we widen then that's certainly bogus considering your UINT_MAX
>> example above. Does
>>
>>
On Fri, Nov 25, 2016 at 2:46 PM, Richard Biener
wrote> On Wed, Nov 16, 2016 at 4:54 PM,
Robin Dapp wrote:
>> Found some time to look into this again.
>>
>>> Index: tree-ssa-propagate.c
>>> ===
>>> --- tree-ssa-propagate.c(rev
On Wed, Nov 16, 2016 at 4:54 PM, Robin Dapp wrote:
> Found some time to look into this again.
>
>> Index: tree-ssa-propagate.c
>> ===
>> --- tree-ssa-propagate.c(revision 240133)
>> +++ tree-ssa-propagate.c(working cop
Ping.
Found some time to look into this again.
> Index: tree-ssa-propagate.c
> ===
> --- tree-ssa-propagate.c(revision 240133)
> +++ tree-ssa-propagate.c(working copy)
> @@ -1105,10 +1105,10 @@ substitute_and_fold_dom_walker
On Tue, Sep 20, 2016 at 2:31 PM, Robin Dapp wrote:
> Hi,
>
>> I meant to do sth like
>>
>> Index: tree-ssa-propagate.c
>> ===
>> --- tree-ssa-propagate.c(revision 240133)
>> +++ tree-ssa-propagate.c(working copy)
>> @@
Ping :)
Ping.
On 09/20/2016 06:31 AM, Robin Dapp wrote:
Hi,
I meant to do sth like
Index: tree-ssa-propagate.c
===
--- tree-ssa-propagate.c(revision 240133)
+++ tree-ssa-propagate.c(working copy)
@@ -1105,10 +1105,10 @@ substitu
Hi,
> I meant to do sth like
>
> Index: tree-ssa-propagate.c
> ===
> --- tree-ssa-propagate.c(revision 240133)
> +++ tree-ssa-propagate.c(working copy)
> @@ -1105,10 +1105,10 @@ substitute_and_fold_dom_walker::before_
[ Another patch I'd started working through, but hadn't completed... ]
On 09/14/2016 07:05 AM, Richard Biener wrote:
On Mon, Aug 22, 2016 at 4:58 PM, Robin Dapp wrote:
if !inner_ovf (just set that to false if !check_inner_ovf to simplify
checks please).
you know it's valid to transform the op
On Mon, Aug 22, 2016 at 4:58 PM, Robin Dapp wrote:
>> if !inner_ovf (just set that to false if !check_inner_ovf to simplify
>> checks please).
>> you know it's valid to transform the op to (T)@0 innerop (T)@1 outerop @2
>> (if T is wider than the inner type which I think you should check and
>> wh
Ping.
diff --git a/gcc/gimple-match-head.c b/gcc/gimple-match-head.c
index 2beadbc..d66fcb1 100644
--- a/gcc/gimple-match-head.c
+++ b/gcc/gimple-match-head.c
@@ -39,6 +39,7 @@ along with GCC; see the file COPYING3. If not see
#include "internal-fn.h"
#include "case-cfn-macros.h"
#include "gimp
gah, this
+ return true;
+ if (TREE_CODE (t1) != SSA_NAME)
should of course be like this
+ if (TREE_CODE (t1) != SSA_NAME)
+ return true;
in the last patch.
> if !inner_ovf (just set that to false if !check_inner_ovf to simplify
> checks please).
> you know it's valid to transform the op to (T)@0 innerop (T)@1 outerop @2
> (if T is wider than the inner type which I think you should check and
> which should
> simplify things).
I simplified the control
On Thu, Jul 21, 2016 at 12:42 PM, Robin Dapp wrote:
> As described in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69526, we
> currently fail to simplify cases like
>
> (unsigned long)(a - 1) + 1
>
> to
>
> (unsigned long)a
>
> when VRP knows that (a - 1) does not overflow.
>
> This patch introduc
27 matches
Mail list logo
