gcc-11-20210321 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20210321 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20210321/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision fc24ea2374259d401a46ce3526688b7e79d4cc13

You'll find:

 gcc-11-20210321.tar.xz   Complete GCC

  SHA256=aab563cf555c595e4527e84c62c1e0557a205293256c5c2b6e17f149fa98dd53
  SHA1=e10419e5a9baefd955ffe76195e071f517b42182

Diffs from 11-20210314 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[RFC] avoid type conversion through versioning loop

[guojiufu via Gcc]

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] = 

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!