Re: Allow matching of side effects in operand_equal_p

2015-11-06 Thread Jan Hubicka
> On Mon, 2 Nov 2015, Jan Hubicka wrote: > > > Hi, > > this patch adds OEP_MATCH_SIDE_EFFECT to tell operand_equal_p that the two > > operands compared are from different code paths and thus they can be matched > > even if they have side effects. > > > > I.e. > > > > volatile int a; > > > > if

Re: Allow matching of side effects in operand_equal_p

2015-11-02 Thread Jan Hubicka
> > But you don't even need the call case for tailmerge or ICF as we don't > have CALL_EXPRs in GIMPLE. No? Sure, it will do the trick only if ?: generic folding is updated to pass OEP_MATCH_SIDE_EFFECTS > > And you mean the difference of OEP_CONSTANT_ADDRESS_OF to > OEP_ADDRESS_OF | OEP_MATCH

Re: Allow matching of side effects in operand_equal_p

2015-11-02 Thread Richard Biener
On Mon, 2 Nov 2015, Jan Hubicka wrote: > Hi, > this patch adds OEP_MATCH_SIDE_EFFECT to tell operand_equal_p that the two > operands compared are from different code paths and thus they can be matched > even if they have side effects. > > I.e. > > volatile int a; > > if (a==a) > > has two rea

Allow matching of side effects in operand_equal_p

2015-11-01 Thread Jan Hubicka
Hi, this patch adds OEP_MATCH_SIDE_EFFECT to tell operand_equal_p that the two operands compared are from different code paths and thus they can be matched even if they have side effects. I.e. volatile int a; if (a==a) has two reads and thus can't be optimized (I guess), while b?a:a can be o