This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH PR71437/V2]Simplify cond with assertions in threading


On 02/16/2017 04:55 AM, Richard Biener wrote:
On Tue, Feb 14, 2017 at 11:05 AM, Bin Cheng <Bin.Cheng@arm.com> wrote:
Hi,
This is the second try fixing PR71437.  The old version patch tried to fix issue in VRP but it requires further non-trivial change in VRP, specifically, to better support variable value ranges.  This is not appropriate at stage 4.  Alternatively, this patch tries to fix issue by improving threading.  It additionally simplifies condition by using assertion conditions.

Bootstrap and test on x86_64 and AArch64.  Is it OK?

Hmm.  So I'm not a big fan of tree_simplify_using_condition ;)  The
case in question for the PR
was an equivalent assert to the condition?  Thus basically
tree_simplify_using_condition (x <= 52, x <= 25)?

+      if (is_gimple_assign (def0)
+         && TREE_CODE (gimple_assign_rhs1 (def0)) == ASSERT_EXPR)

gimple_assign_rhs_code (def0) == ASSERT_EXPR

As you add a parameter to tree_simplify_using_condition you can as well fold
it into tree_simplify_using_condition_1.  And ideally I'd like to see us pass in
a decomposed toplevel expression to avoid

+         tree res = fold_build2 (cond_code, boolean_type_node,
+                                 assert_op0, assert_op1);

but I'm not sure that will work out ;)

So, in the end I wonder if we can fix this in threading w/o usign
tree_simplify_using_conditon
(the main issue with it I have is the extensive tree building it does).
Given that we've got a callback into VRP simplifiers, I'd think we ought to be able to avoid tree_simplify_using_condition.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]