[LLVMdev] LLVM 2.8 and MMX

Nicolas Capens nicolas.capens at gmail.com
Wed Sep 8 00:35:40 PDT 2010


Hi Chris,

 

It's not broken, but the performance is crippled.

 

I noticed that the code still contains some MMX instructions, but several
operations get expanded (apparently swizzling and such get expanded to a
large number of byte moves).

 

I could use intrinsics, but they wouldn't be optimized like other vector
operations. I could use SSE operations, but they would increase SSE register
pressure while MMX registers are left unused.

 

So ideally I would like to inform LLVM that selecting MMX instructions is
fine. I'm inserting emms instructions in the right spots myself.

 

Thanks,

 

Nicolas

 

From: Chris Lattner [mailto:clattner at apple.com] 
Sent: Tuesday, September 07, 2010 17:42
To: Nicolas Capens
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] LLVM 2.8 and MMX

 

 

On Sep 7, 2010, at 7:45 AM, Nicolas Capens wrote:





Hi all,

 

I've tested a recent revision and noticed that using 64-bit vectors became
very slow. It looks like they are expanded to non-MMX instructions to avoid
breaking code which does not clear the MMX state using emms?

 

For my project I'm already manually inserting emms instructions in the right
places, so I'd really like 64-bit vector operations to be lowered to MMX
instructions for best performance. So is there some way to get that behavior
back? I tried making IsVerbotenVectorType return false but that didn't
appear to help.

 

I would be very grateful if someone would add a switch to disable the
expanding before the 2.8 release is finalized.

 

The implementation of MMX is in a state of flux: the plan is to stop generic
vectors from being selected to mmx operations, and add intrinsics for every
mmx operations (including add).  However, 2.8 shouldn't be broken, that
would be a serious regression.  Please file a bug with a small example.
Thanks!

 

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100908/154ec1fb/attachment.html>


More information about the llvm-dev mailing list