This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Reenable CSE of non-volatile inline asm (PR rtl-optimization/63637)


Segher Boessenkool <segher@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]