https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #12 from kugan at gcc dot gnu.org --- (In reply to rsand...@gcc.gnu.org from comment #10) > (In reply to kugan from comment #9) > > Created attachment 46040 [details] > > patch > > Wasn't sure whether this patch was WIP or the final version > for review, but we need to do something more generic than > dividing by 4. I think the test will still fail with "int" > changed to "short" for example. > > I also don't think the new candidate should be tied to the > mask/load store functions. Maybe one approach would be to > check when adding a zero-based candidate for a use in: > > /* Record common candidate with initial value zero. */ > basetype = TREE_TYPE (iv->base); > if (POINTER_TYPE_P (basetype)) > basetype = sizetype; > record_common_cand (data, build_int_cst (basetype, 0), iv->step, use); > > whether the use actually benefits from this unscaled iv. > If the use is USE_REF_ADDRESS, we could compare the cost > of an address with an unscaled index with the cost of an address > with a scaled index. I think the natural scale value to try > would be GET_MODE_INNER (TYPE_MODE (mem_type)). Thanks for the comments. I agree this is the right place. But I am not sure if checking the cost at this point is what IV opt generally does. In general, IV-opt adds candidates which can be helpful and later decides the optimal set. If we are to use get_computation_cost to see the costs, we have to create iv_cand and then discard. Since we are adding only one candidate and that too for SVE like targets, I am thinking that it is OK. If you still prefer to check the cost, I will change that. Attached patch (only the ivopt changes) and testcase
