[Issue 5688] Poor optimization of (long & 1)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5688

Dmitry Olshansky  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dmitry.o...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #3 from Dmitry Olshansky  ---
Now on 2.080 32-bit it's much better:

   0:   8b 44 24 04 mov0x4(%esp),%eax
   4:   8b 54 24 08 mov0x8(%esp),%edx
   8:   25 01 00 00 00  and$0x1,%eax
   d:   31 d2   xor%edx,%edx
   f:   c2 08 00ret$0x8

And 64-bit (barring the rbp/rsp that can be elided but a different matter):


   0:   55  push   %rbp
   1:   48 8b ecmov%rsp,%rbp
   4:   48 81 e7 01 00 00 00and$0x1,%rdi
   b:   48 89 f8mov%rdi,%rax
   e:   5d  pop%rbp
   f:   c3  retq

--

[Issue 5688] Poor optimization of (long 1)

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=5688

Andrei Alexandrescu and...@erdani.com changed:

   What|Removed |Added

Version|D1  D2 |D2

--

[Issue 5688] Poor optimization of (long 1)

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=5688


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com


--- Comment #1 from Walter Bright bugzi...@digitalmars.com 2011-03-03 
11:49:26 PST ---
Interestingly, if the code is written as:

bool foo(long v)
{
return  (v  1) == 1;
}

the code generated is:

mov EAX,4[ESP]
mov EDX,8[ESP]
and EAX,1
xor EDX,EDX
ret 8

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 5688] Poor optimization of (long 1)

[d-bugmail]

http://d.puremagic.com/issues/show_bug.cgi?id=5688



--- Comment #2 from Don clugd...@yahoo.com.au 2011-03-03 17:52:46 PST ---
(In reply to comment #1)
 Interestingly, if the code is written as:
 
 bool foo(long v)
 {
 return  (v  1) == 1;
 }
 
 the code generated is:
 
 mov EAX,4[ESP]
 mov EDX,8[ESP]
 and EAX,1
 xor EDX,EDX
 ret 8

I noticed that. And even though that's better, both uses of EDX are completely
unnecessary.
Changing  cgelem.c, elcmp(), around line 3350 to this:

case 8:
-e = el_una(OP64_32,TYlong,e);
+e-E1 = el_una(OP64_32,TYint,e-E1);
+e-E2 = el_una(OP64_32,TYint,e-E2);
break;
makes it create optimal code, although that's probably incorrect for 64 bits.
The way elcmp() works looks pretty bizarre to me.
But it's the return ( v  1); case that is the primary problem.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---