[RFC] avoid type conversion through versioning loop

guojiufu guojiufu@imap.linux.ibm.com
Mon Mar 22 06:39:56 GMT 2021


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!


More information about the Gcc mailing list