Bug 124869 – Optimize away OR with zero - a common ASM.js pattern.

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Nadav Rotem]

Optimize away OR with zero - a common ASM.js pattern.

[Nadav Rotem]

Created attachment 217843 [details]
Patch

[Nadav Rotem]

Created attachment 217844 [details]
Patch

[Filip Pizlo]

Comment on attachment 217844 [details]
Patch

This feels somewhat suboptimal - ideally we would allow for copy-propagation of y = (x|0), which this doesn't do.  I recommend doing this in the FixupPhase instead.  The way that you would do it is replace BitOr(x, 0) with Identity(x) ; Phantom(0).  The Phantom(0) is relevant because want to know that the constant zero was live up to that point.

[Nadav Rotem]

I also thought that it would be a good idea to peephole it earlier.   Should we also keep this one?

[Filip Pizlo]

(In reply to comment #4)
> I also thought that it would be a good idea to peephole it earlier.   Should we also keep this one?

Nah - in fact what I would do is have:

- An earlier peephole in FixupPhase.

- A "later" peephole in MacroAssemblerBlah.h, where Blah = x86_64 | ARMv7 | ARM64.  This would help the other JITs - including our regex JIT. ;-)

[Nadav Rotem]

Created attachment 217864 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 217864 [details]
Patch

Clearing flags on attachment: 217864

Committed r159783: <http://trac.webkit.org/changeset/159783>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Nadav Rotem]

Filip, can we do this:

 void add32(TrustedImm32 imm, RegisterID dest)
 {   
         if (imm.m_value)                   <---------- this
             add32(imm, dest, dest);
 }


someone may be calling add32 just to use the flags.  When is it safe to optimize code in the emitter ?