llvm dev - Apr 2013 - [LLVMdev] Another missed optimization opportunity?

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

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu]
> On Behalf Of Scott Pakin
> Subject: Re: [LLVMdev] Another missed optimization opportunity?
> > 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.
The myarray variable could be defined and initialized like this:

    int* myarray = ((int*)&myarray) - 5;

If the initialization occurs external to the module with the incrementation
function, the optimizers must assume such silliness is possible in lieu of any
information to the contrary, so aliasing can occur.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.

On 04/24/2013 02:35 PM, Caldarale, Charles R wrote:
> The myarray variable could be defined and initialized like this:
>
>      int* myarray = ((int*)&myarray) - 5;
>
> If the initialization occurs external to the module with the incrementation
function, the optimizers must assume such silliness is possible in lieu of any
information to the contrary, so aliasing can occur.
I see.  Pretty evil stuff.  But that does explain how three myarray[5]++'s
can potentially be different from one myarray[5]+=3.

Thanks for the example,
-- Scott