On Mon, Mar 22, 2021 at 7:41 AM guojiufu via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hi All,
>
> As we know, type conversion is not in favor of optimization, and may
> cause performance issue.
>
> For example:
> for (unsigned int i = 0; i < n; ++i)
> a[m + i] = 1; //or a[30 + i] = xxxx
>
> In this code, the index to access arrays is 'unsinged int' (32bit),
> while the register operations (like index increase i++) would on longer
> bits
> on 64bit machines, and then conversion between 32bits and 64bits and
> happen.
>
> 19: L19:
> 10: NOTE_INSN_BASIC_BLOCK 4
> 11: %9:DI=%5:DI<<0x2
> 17: %5:SI=%5:SI+0x1
> 18: %5:DI=zero_extend(%5:SI) #clear high 32bits
> 14: [%3:DI+%9:DI]=%10:SI
> 40: {pc={(ctr:DI!=0x1)?L19:pc};ctr:DI=ctr:DI-0x1;clobber scratch;clobber
> scratch;}
>
> In some cases, the shorter integer type would not overflow,
> and then the type conversion could be eliminated in some cases.
> So, I'm thinking of an optimization to avoid those conversions.
> The idea looks like current loop-versioning. Using the above example:
>
> for (unsigned int i = 0; i < n; ++i)
> a[30 + i] = 1;
>
> change to:
>
> if (n <= UINT_MAX) // ++i does not cause overflow, n + 30 <= UINT_MAX
> for (long l_i = 0; l_i < l_n; ++l_i)
> a[30 + l_i] = 1;
> else
> for (unsigned int i = 0; i < n; ++i)
> a[30 + i] = 1;
>
> With this kind of transformation, it would be in favor of scev, and
> some other optimizations could be beneficial: like vectorization.
>
> How about this idea? Thanks for any comments!
Better than doing loop versioning is to enhance SCEV (and thus also
dependence analysis) to track extra conditions they need to handle
cases similar as to how niter analysis computes it's 'assumptions'
condition. That allows the versioning to be done when there's an
actual beneficial transform (like vectorization) rather than just
upfront for the eventual chance that there'll be any. Ideally such
transform would then choose IVs in their transformed copy that
are analyzable w/o repeating such versioning exercise for the next
transform.
Richard.
