Segher Boessenkool 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:
>>
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(voi
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("#
On Fri, Jan 23, 2015 at 12:52:37PM -0800, Richard Henderson wrote:
> > ./sysdeps/generic/malloc-machine.h:# define atomic_full_barrier() __asm (""
> > ::: "memory")
>
> I think that it's uses like these -- which may well have been written
> by folks that also work on gcc -- that are proof that we
On 01/15/2015 12:13 AM, Jakub Jelinek wrote:
> On Thu, Jan 15, 2015 at 07:46:18AM +0100, Richard Biener wrote:
That last line means the compiler is free to delete a non-volatile
asm with a memory clobber if that asm is not needed for dataflow. Or
that is how I read it; it is trying
On 01/15/15 01:13, Jakub Jelinek wrote:
The glibc barriers are supposedly something that can be CSEd (one barrier
instead of
two consecutive barriers is enough), but certainly not moved across any
loads/stores
in between. In the kernel case, the enable/disable probably wouldn't allow
even CS
On Thu, Jan 15, 2015 at 09:13:30AM +0100, Jakub Jelinek wrote:
> differently. Just trying to grep for a few:
> glibc:
> ./sysdeps/alpha/bits/atomic.h:# define atomic_full_barrier() __asm ("mb" : :
> : "memory");
> ./sysdeps/alpha/bits/atomic.h:# define atomic_read_barrier() __asm ("mb" : :
> :
On Thu, 15 Jan 2015, Jakub Jelinek wrote:
> On Thu, Jan 15, 2015 at 07:46:18AM +0100, Richard Biener wrote:
> > >> That last line means the compiler is free to delete a non-volatile
> > >> asm with a memory clobber if that asm is not needed for dataflow. Or
> > >> that is how I read it; it is try
On Thu, Jan 15, 2015 at 07:46:18AM +0100, Richard Biener wrote:
> >> That last line means the compiler is free to delete a non-volatile
> >> asm with a memory clobber if that asm is not needed for dataflow. Or
> >> that is how I read it; it is trying to indicate that if you want to
> >> prevent th
On January 15, 2015 6:06:33 AM CET, Jeff Law wrote:
>On 01/14/15 08:19, Segher Boessenkool wrote:
>
>> "
>> @findex clobber
>> @item (clobber @var{x})
>> Represents the storing or possible storing of an unpredictable,
>> undescribed value into @var{x}, which must be a @code{reg},
>> @code{scratch}
On 01/14/15 08:19, Segher Boessenkool wrote:
"
@findex clobber
@item (clobber @var{x})
Represents the storing or possible storing of an unpredictable,
undescribed value into @var{x}, which must be a @code{reg},
@code{scratch}, @code{parallel} or @code{mem} expression.
[...]
If @var{x} is @code
On Tue, Jan 13, 2015 at 11:16:09PM -0700, Jeff Law wrote:
> On 01/13/15 17:03, Segher Boessenkool wrote:
> >On Tue, Jan 13, 2015 at 03:17:08PM -0700, Jeff Law wrote:
> >>>And finally there is the case of non-volatile asm with "memory" clobber
> >>>with
> >>>no memory stores in between the two - the
On 01/13/15 09:18, Jakub Jelinek wrote:
Hi!
My PR60663 fix unfortunately stopped CSE of all inline-asms, even when
they e.g. only have the clobbers added by default.
This patch attempts to restore the old behavior, with the exceptions:
1) as always, asm volatile is not CSEd
2) inline-asm with m
On 01/13/15 17:03, Segher Boessenkool wrote:
On Tue, Jan 13, 2015 at 03:17:08PM -0700, Jeff Law wrote:
And finally there is the case of non-volatile asm with "memory" clobber
with
no memory stores in between the two - the posted (safer) patch will not
allow to CSE the two, while in theory we cou
On Tue, Jan 13, 2015 at 03:17:08PM -0700, Jeff Law wrote:
> >And finally there is the case of non-volatile asm with "memory" clobber
> >with
> >no memory stores in between the two - the posted (safer) patch will not
> >allow to CSE the two, while in theory we could CSE them into just one asm.
> I
On Tue, Jan 13, 2015 at 12:45:27PM -0700, Jeff Law wrote:
> On 01/13/15 09:38, Segher Boessenkool wrote:
> >On Tue, Jan 13, 2015 at 05:18:19PM +0100, Jakub Jelinek wrote:
> >>3) on request from Richard (which Segher on IRC argues against), "memory"
> >>clobber also prevents CSE;
> >
> >As exten
On 01/13/15 13:13, Jakub Jelinek wrote:
On Tue, Jan 13, 2015 at 12:45:27PM -0700, Jeff Law wrote:
On 01/13/15 09:38, Segher Boessenkool wrote:
On Tue, Jan 13, 2015 at 05:18:19PM +0100, Jakub Jelinek wrote:
3) on request from Richard (which Segher on IRC argues against), "memory"
clobber al
On Tue, Jan 13, 2015 at 12:45:27PM -0700, Jeff Law wrote:
> On 01/13/15 09:38, Segher Boessenkool wrote:
> >On Tue, Jan 13, 2015 at 05:18:19PM +0100, Jakub Jelinek wrote:
> >>3) on request from Richard (which Segher on IRC argues against), "memory"
> >>clobber also prevents CSE;
> >
> >As exten
On 01/13/15 09:38, Segher Boessenkool wrote:
On Tue, Jan 13, 2015 at 05:18:19PM +0100, Jakub Jelinek wrote:
3) on request from Richard (which Segher on IRC argues against), "memory"
clobber also prevents CSE;
As extend.texi used to say:
"
If your assembler instructions access memory in an
On Tue, Jan 13, 2015 at 05:18:19PM +0100, Jakub Jelinek wrote:
> 3) on request from Richard (which Segher on IRC argues against), "memory"
>clobber also prevents CSE;
As extend.texi used to say:
"
If your assembler instructions access memory in an unpredictable
fashion, add @samp{memory} to t
20 matches
Mail list logo
