This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Reenable CSE of non-volatile inline asm (PR rtl-optimization/63637)
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Richard Henderson <rth at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, Jeff Law <law at redhat dot com>, Richard Biener <rguenther at suse dot de>, Eric Botcazou <ebotcazou at adacore dot com>, gcc-patches at gcc dot gnu dot org
- Date: Sat, 24 Jan 2015 11:53:26 +0000
- Subject: Re: [PATCH] Reenable CSE of non-volatile inline asm (PR rtl-optimization/63637)
- Authentication-results: sourceware.org; auth=none
- References: <54B59964 dot 7070707 at redhat dot com> <20150114000315 dot GA32710 at gate dot crashing dot org> <54B609A9 dot 9090800 at redhat dot com> <20150114151906 dot GA21784 at gate dot crashing dot org> <54B74AD9 dot 4010905 at redhat dot com> <DE331E6C-39D7-4F70-9E25-A3A4F7F49640 at gmail dot com> <20150115081330 dot GB1405 at tucnak dot redhat dot com> <54C2B495 dot 2010009 at redhat dot com> <20150123213940 dot GA17134 at gate dot crashing dot org> <20150123214850 dot GZ1746 at tucnak dot redhat dot com> <20150124011858 dot GA31255 at gate dot crashing dot org>
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