Segher Boessenkool <seg...@kernel.crashing.org> writes:
> On Fri, Jan 23, 2015 at 10:48:50PM +0100, Jakub Jelinek wrote:
>> On Fri, Jan 23, 2015 at 03:39:40PM -0600, Segher Boessenkool wrote:
>> > I understand that argument.  But it is not what GCC actually does, nor
>> > what I think it should do.  Consider this program:
>> > 
>> > --- 8< ---
>> > int main(void)
>> > {
>> >    int x[100], y[100];
>> > 
>> >    x[31] = 42;
>> > 
>> >    asm("# eww %0" : "=m"(y[4]) : : "memory");
>> > 
>> >    return 0;
>> > }
>> > --- 8< ---
>> 
>> Here x isn't addressable, so it is certainly fine to DSE it.
>> x shouldn't be considered memory.
>> If the address of x escaped, either to the assembly or to some global var
>> etc., then it probably shouldn't be removed.
>
> But GCC does consider it memory.  If you look at the (tree) dump files
> you see both arrays are clobbered after the asm.  Tree DCE removes the
> store to x[31] nevertheless.
>
> If the address of x escapes then of course the store to x[31] should
> not be removed, irrespective of whether the clobber implies a read
> or not.

Just tried some other examples out of curiosity.  In:

int main(void)
{
  int x[100], y[100];

  asm volatile("# foo" :: "r"(x));
  x[31] = 42;
  asm("# eww %0" : "=m"(y[4]) : : "memory");

  return 0;
}

"x[31]" can only validly escape to the second asm.  In this case the
assignment is kept, as it is with:

int main(void)
{
  int x[100], y;

  asm volatile("# foo" :: "r"(x));
  x[31] = 42;
  asm("# eww %0" : "=r"(y) : : "memory");

  return y;
}

But remove the clobber and it goes away:

int main(void)
{
  int x[100], y;

  asm volatile("# foo" :: "r"(x));
  x[31] = 42;
  asm("# eww %0" : "=r"(y));

  return y;
}

So it looks like these four cases (including yours) are handled correctly.

Thanks,
Richard

Reply via email to