search for: bevalue

...lly want? The case of an expression with mixed operator ('add' with and without nsw) flag would require an explicit representation of the two operator making more complex reassociation, simplification and reordering of the expression operands. Your proposed workaround of checking that the BEValue is an operation between the PHINode Value and a loop invariant would be fine but it's still a workaround. -Michele

...of an expression with mixed operator ('add' with and without nsw) flag > would require an explicit representation of the two operator making more complex > reassociation, simplification and reordering of the expression operands. > > Your proposed workaround of checking that the BEValue is an operation between > the PHINode Value and a loop invariant would be fine but it's still a workaround. If it's legal to reassociate a mix of 'add' and 'add nsw' then the poison value propagation would make the NSW inference on the whole expression correct. On the co...

...operator making more complex > reassociation, simplification and reordering of the expression operands. Yes, in general an attempt to preserve NSW flags would defeat the simple utility of SCEV. That’s why we drop the flags all over the place. > Your proposed workaround of checking that the BEValue is an operation between > the PHINode Value and a loop invariant would be fine but it's still a workaround. This fixes a correctness problem I noticed in the same bit of code (PR17452). My suggestion was to be conservative in preserving NSW. It’s not about missing optimizations. I don’t ha...

...that is present in the SUB instruction is not propagated in the > AddRec. > > Looking in the source code I analyzed the construction of the SCEV for a PHINode > and during the analysis of the loop-invariant part of the increment the flags > NSW/NUW are set according to the Operator BEValueV > (ScalarEvoluton.cpp:3099-3113), but only Add and GEP operators are checked. > > //-------------------------------------------------------------------------// > if (const AddOperator *OBO = dyn_cast<AddOperator>(BEValueV)) { > if (OBO->hasNoUnsignedWrap()) > Flags...

...omplex >> reassociation, simplification and reordering of the expression operands. > > Yes, in general an attempt to preserve NSW flags would defeat the simple utility of SCEV. That’s why we drop the flags all over the place. > >> Your proposed workaround of checking that the BEValue is an operation between >> the PHINode Value and a loop invariant would be fine but it's still a workaround. > > This fixes a correctness problem I noticed in the same bit of code (PR17452). My suggestion was to be conservative in preserving NSW. It’s not about missing optimization...

...ody> but the NSW flag that is present in the SUB instruction is not propagated in the AddRec. Looking in the source code I analyzed the construction of the SCEV for a PHINode and during the analysis of the loop-invariant part of the increment the flags NSW/NUW are set according to the Operator BEValueV (ScalarEvoluton.cpp:3099-3113), but only Add and GEP operators are checked. //-------------------------------------------------------------------------// if (const AddOperator *OBO = dyn_cast<AddOperator>(BEValueV)) { if (OBO->hasNoUnsignedWrap()) Flags = setFlags(Flags, SCEV::Flag...

...Return a SCEV corresponding to a conversion of the /// input value to the specified type. If the type must be extended, it is zero /// extended. @@ -3029,13 +3040,22 @@ const SCEV *ScalarEvolution::createNodeForPHI(PHINode *PN) { if (const SCEVAddExpr *Add = dyn_cast<SCEVAddExpr>(BEValue)) { // If there is a single occurrence of the symbolic value, replace it // with a recurrence. + const SCEVZeroExtendExpr *zext = 0; + const SCEVTruncateExpr *trunc = 0; unsigned FoundIndex = Add->getNumOperands(); - for (unsigned i = 0...