https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #10 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org>
---
(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)).
