On Thu, 16 Mar 2017, Jeff Law wrote:
On 03/16/2017 06:54 AM, Trevor Saunders wrote:
+ if (TREE_CODE (op0) == SSA_NAME && integer_zerop (op1))
+ {
+ enum tree_code code = eq->cond.ops.binary.op;
+ if ((code == EQ_EXPR && eq->value == boolean_true_node)
+
On Thu, Mar 16, 2017 at 09:03:43AM -0600, Jeff Law wrote:
> On 03/16/2017 06:54 AM, Trevor Saunders wrote:
> > > + if (TREE_CODE (op0) == SSA_NAME && integer_zerop (op1))
> > > + {
> > > + enum tree_code code = eq->cond.ops.binary.op;
> > > + if ((code == EQ_EXPR && eq->value == b
On 03/16/2017 06:54 AM, Trevor Saunders wrote:
+ if (TREE_CODE (op0) == SSA_NAME && integer_zerop (op1))
+ {
+ enum tree_code code = eq->cond.ops.binary.op;
+ if ((code == EQ_EXPR && eq->value == boolean_true_node)
+ || (code == NE_EXPR &&
On Wed, Mar 15, 2017 at 09:18:27PM -0600, Jeff Law wrote:
> On 03/15/2017 09:17 PM, Jeff Law wrote:
> >
> > Patch #3 will remove handle_dominating_asserts from the core of the jump
> > threading code and push it into VRP's callbacks where it should always
> > have been.
> >
> > As a side effect i
On 03/15/2017 09:17 PM, Jeff Law wrote:
Patch #3 will remove handle_dominating_asserts from the core of the jump
threading code and push it into VRP's callbacks where it should always
have been.
As a side effect it causes some code which was previously only used for
threading from VRP to be use
Patch #3 will remove handle_dominating_asserts from the core of the jump
threading code and push it into VRP's callbacks where it should always
have been.
As a side effect it causes some code which was previously only used for
threading from VRP to be used unconditionally. It's actually a g
