[LLVMdev] Another missed optimization opportunity?

[Scott Pakin]

On 04/24/2013 01:29 PM, Caldarale, Charles R wrote:
> Is this a potential aliasing effect?  Since myarray is defined as a pointer, not an array, it's theoretically possible that the address therein refers to the same memory location as the pointer itself.

I was thinking along those lines, but I haven't been able to come up
with a specific instance of what could possibly be aliased.

Here are some additional observations that might be helpful in solving
this mystery:

   1) The increments are in fact coalesced when myarray is declared as
      an array instead of a pointer:

           @myarray = external global [10 x i32]

           define void @update_array() #0 {
             %1 = load i32* getelementptr inbounds ([10 x i32]* @myarray, i64 0, i64 5), align 4
             %2 = add nsw i32 %1, 3
             store i32 %2, i32* getelementptr inbounds ([10 x i32]* @myarray, i64 0, i64 5), align 4
             ret void
           }

   2) Both clang and gcc optimize the analogous C code into an
      increment by 3:

           extern int *myarray;

           void update_array (void)
           {
             myarray[5]++;
             myarray[5]++;
             myarray[5]++;
           }

      This would imply that the issue is not related to semantics.

   3) opt *does* optimize the code when myarray is declared as a
      constant pointer to variable data as opposed to a variable
      pointer to variable data:

           @myarray = external constant i32*

      This would imply that the issue *is* related to semantics.  Sigh.

-- Scott