Richard Kenner wrote:
t1 = y | 2;
y = t1;
are very hard to tell apart at the RTL level. Though it's clear that
a single instruction might best match the expect semantics of the former,
it's a lot less clear that it would for the latter.
I think it would still be OK for the latt
> > t1 = y | 2;
> > y = t1;
> >
> > are very hard to tell apart at the RTL level. Though it's clear that
> > a single instruction might best match the expect semantics of the former,
> > it's a lot less clear that it would for the latter.
>
> I think it would still be OK for the latter,
Richard Kenner wrote:
Right, but it would seem this is a good canididate for combination. This
is especially true since often Volatile is used with the sense of Atomic
in Ada, and it is not a bad idea to combine these in practice, giving an
atomic update (right, nothing in the language requires i
> Right, but it would seem this is a good canididate for combination. This
> is especially true since often Volatile is used with the sense of Atomic
> in Ada, and it is not a bad idea to combine these in practice, giving an
> atomic update (right, nothing in the language requires it, but it is
> d
Richard Kenner wrote:
OK, sounds reasonable, but then I don't understand the logic behind
avoiding this instruction sequence for the volatile case, this is
two accesses at the bus level so what's the difference?
There's no difference from that perspective. The logic behind what's
generated is
> OK, sounds reasonable, but then I don't understand the logic behind
> avoiding this instruction sequence for the volatile case, this is
> two accesses at the bus level so what's the difference?
There's no difference from that perspective. The logic behind what's
generated is that instead of tr
Samuel Tardieu wrote:
For this pattern (isolated setting of one bit in the middle of a byte at
a random memory location), this is the best code on this platform AFAIK.
As an evidence, if you mark neither variable as volatile GCC generates
with -O3 -fomit-frame-pointer:
f:
orb $16,
On 1/12, Robert Dewar wrote:
>> I cannot see a reason not to use "orb $32,y" here instead of a three
>> steps read/modify/write operation. Is this only a missed optimization?
>> (in which case I will open a PR)
>
> Are you sure it is an optimization, the timing on these things is
> very subtle. W
Samuel Tardieu wrote:
When looking at an Ada PR, I stumbled upon the equivalent of the
following C code:
unsigned char x;
volatile unsigned char y;
void f ()
{
x |= 16;
y |= 32;
}
With trunk/i686, the following code is generated (-O3 -fomit-frame-pointer):
f:
movzbl y
> volatile unsigned char y;
> void f ()
> {
> y |= 32;
> }
>
> I cannot see a reason not to use "orb $32,y" here instead of a three
> steps read/modify/write operation. Is this only a missed optimization?
No, it's purposeful. The idea was that this is completely equivalent to
y =
When looking at an Ada PR, I stumbled upon the equivalent of the
following C code:
unsigned char x;
volatile unsigned char y;
void f ()
{
x |= 16;
y |= 32;
}
With trunk/i686, the following code is generated (-O3 -fomit-frame-pointer):
f:
movzbl y, %eax
orb $
11 matches
Mail list logo
