search for: isinductionphi

Adding support for FP inductions through isInductionPHI() is certainly possible, I have a relatively small local patch that does exactly that for simple fp add-recurrence cases, along with changes to the vectorizer to make it aware of FP inductions. It won't get give you the powerful reasoning capabilities of SCEV, but for the B-like cases it should...

...most of Graphics shading language use case mentioned by Owen should be handled here. It certainly has the logic of detecting FP induction, but Andy punted discussions on non-integer valued IV issues to MichaelZ and Adam. 3) extend InductionDescriptor::isInductionPHI in the vectorizer to directly analyze the PHIs without SCEV support (mentioned by Adam) If this is the standard way to deal with all secondary inductions, it certainly looks attractive. Elena, would you try doing this and compare with 1)? Thanks, Hideki -----------...

> One option would be to extend InductionDescriptor::isInductionPHI in the vectorizer to directly analyze the PHIs without SCEV support as Sanjoy suggested. I *think* that that could be sufficient to handle case B. I implemented this with FP SCEV and the code looks very structured, including SCEVExpander. Extending the existing structures without implementing FP...

...not for *B*. On the specific issue of non-integer values, there is simply no attempt made in the code to deal with them. That said, I think it should be possible to compute the trip count and then derive an integer induction variable controlling the loop. > 3) > extend InductionDescriptor::isInductionPHI in the vectorizer to directly analyze the PHIs without SCEV support > (mentioned by Adam) > If this is the standard way to deal with all secondary inductions, it certainly looks attractive. > Elena, would you try doing this and compare with 1)? Just to clar...

Demikhovsky, Elena wrote: > > Even then, I'd personally want to see further evidence of why the > correct solution is to model the floating point IV in SCEV rather than > find a more powerful way of converting the IV to an integer that models > > the non-integer values taken on by the IV. As an example, if the use > case is the following code with appropriate flags to

My response to this patch is below, but adding a floating-point feature to SCEV should really be hashed out on the llvm-dev list first. I would like to get the attention of floating-point experts on the design review. I’d like to see a small design proposal justifying the feature and defending it’s soundness. My concern is that the approach may not be sound, but providing this core API would

...rV2::getValueType 36 getBaseAlign 35 getAdjustedPtr 33 llvm::InductionDescriptor::isInductionPHI 32 promoteArguments 29 isSupportedType 28 matchIntrinsicType...