We would like to simplify code like
(larger_type)(var + const1) + const2
to
(larger_type)(var + combined_const1_const2)
when we know that no overflow happens.
---
gcc/match.pd | 101 +++
1 file changed, 101 insertions(+)
diff --git a/gcc/match.pd
On Tue, 13 Aug 2019, Robin Dapp wrote:
+/* ((T)(A)) + CST -> (T)(A + CST) */
+#if GIMPLE
+ (simplify
+ (plus (convert SSA_NAME@0) INTEGER_CST@1)
+(if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
+ && INTEGRAL_TYPE_P (type)
I have become rather wary of INTEGRAL_TYPE_P recently because it i
> I have become rather wary of INTEGRAL_TYPE_P recently because it
> includes enum types, which with -fstrict-enum can have a surprising
> behavior. If I have
> enum E { A, B, C };
> and e has type enum E, with -fstrict-enum, do your tests manage to
> prevent (long)e+1 from becoming (long)(e+1) wit
On 8/13/19 2:33 AM, Robin Dapp wrote:
> We would like to simplify code like
> (larger_type)(var + const1) + const2
> to
> (larger_type)(var + combined_const1_const2)
> when we know that no overflow happens.
> ---
> gcc/match.pd | 101 +++
> 1 file
> +/* ((T)(A + CST1)) + CST2 -> (T)(A) + CST */
> Do you want to handle MINUS? What about POINTER_PLUS_EXPR?
When I last attempted this patch I had the MINUS still in it but got
confused easily by needing to think of too many cases at once leading to
lots of stupid mistakes. Hence, I left it ou
On 8/13/19 2:42 PM, Robin Dapp wrote:
>> +/* ((T)(A + CST1)) + CST2 -> (T)(A) + CST */
>> Do you want to handle MINUS? What about POINTER_PLUS_EXPR?
>
> When I last attempted this patch I had the MINUS still in it but got
> confused easily by needing to think of too many cases at once leading to
On Tue, 13 Aug 2019, Robin Dapp wrote:
diff --git a/gcc/match.pd b/gcc/match.pd
index 0317bc704f7..94400529ad8 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2020,6 +2020,107 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(if (cst && !TREE_OVERFLOW (cst))
(plus { cst; } @0
+/* ((T)(A +
On Tue, Aug 13, 2019 at 10:36 AM Robin Dapp wrote:
>
> We would like to simplify code like
> (larger_type)(var + const1) + const2
> to
> (larger_type)(var + combined_const1_const2)
> when we know that no overflow happens.
Trowing in my own comments...
> ---
> gcc/match.pd | 101 ++
> So - what are you really after? (sorry if I don't remeber, testcase(s)
> are missing
> from this patch)
>
> To me it seems that 1) loses information if A + CST was done in a signed type
> and we know that overflow doesn't happen because of that. For the reverse
> transformation we don't. Btw,
On Fri, Aug 16, 2019 at 2:17 PM Robin Dapp wrote:
>
> > So - what are you really after? (sorry if I don't remeber, testcase(s)
> > are missing
> > from this patch)
> >
> > To me it seems that 1) loses information if A + CST was done in a signed
> > type
> > and we know that overflow doesn't happe
> So - which case is it? IIRC we want to handle small signed
> constants but the code can end up unsigned. For the
> above we could write (unsigned long)((int)a + 1 - 1) and thus
> sign-extend? Or even avoid this if we know the range.
> That is, it becomes the first case again (operation perform
On Tue, Aug 20, 2019 at 10:37 AM Robin Dapp wrote:
>
> > So - which case is it? IIRC we want to handle small signed
> > constants but the code can end up unsigned. For the
> > above we could write (unsigned long)((int)a + 1 - 1) and thus
> > sign-extend? Or even avoid this if we know the range.
I'm going to commit the attached two patches. Removed the redundant
changes in test cases and added constructor initialization of
fold_all_stmts.
Regards
Robin
--
gcc/ChangeLog:
2019-08-21 Robin Dapp
* gimple-loop-versioning.cc (loop_versioning::record_address_fragment):
A
13 matches
Mail list logo
