AMD only 'prefetchw' instruction is generated in x64 optimized code. - by jcopenha

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 697740 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 10/28/2011 11:26:01 AM
Access Restriction Public


The attached sample code and project emits a 'prefetchw' instruction when compiled with full optimizations for x64.  This instruction is an AMD specific instruction and on most Intel chips is a no-op, however we have found at least one chip where this produces a fault.

According this to this document, (the "Prefetch Instruction" section) there are at least 6 known Intel models where this will generate an undefined instruction fault.

Since this is a processor specific instruction it seems like it shouldn't be emitted unless specifically requested.  The only way I've found to get rid of it is to not enable optimizations, either around the specific PushTo function or the project in general.  

If you compare the ASM for PushTo and the unoptimized PushTo2 you'll see there is a very large impact to number of instructions.  The unoptimized version is not suitable and we wrote our own version in ASM, just omitting the 'prefetchw' instruction.
Sign in to post a comment.
Posted by Microsoft on 11/8/2011 at 12:43 PM
Hi Jason,

I found the repro you provided. Normally a repro propagates to the tool we use to access a post, but that did not happen in this case. Looking a bit deeper (and where you suggested) I was able to download it. Thanks.

The repro you provided emits the PREFETCHW instruction when compiling to target x64 with optimization on.

This behavior is expected. The Windows operating system has support to trap an illegal instruction exception on PREFETCHW, modifying it to a multibyte NOP to avoid the exception in the future. Of course, if no exception occurs, no change is made.

A bit of history is useful here.

When the original port of our compiler to target x64 was done, only AMD hardware existed. And, at that time, the PREFETCHW instruction was deemed beneficial, so we emitted it.

At some point after this, Intel hardware was released that supported x64. Of course, that hardware did not support the PREFETCHW instruction. Given this and the fact that the instruction does not modify data, registers, or flags, the Windows team added support to handle the illegal instruction -- i.e. the offending 0f 0d modrm PREFETCHW encoding is modified, likely becoming 0f 1f modrm which is a multi-byte NOP. With this support our compiler continues to emit the PREFETCHW instruction.

I hope this helps explain what you are seeing.

Thank you,
Visual Studio Product Team
Posted by jcopenha on 11/7/2011 at 9:23 AM
When I click "expand" next to "Details" it shows that I'm able to download the I've downloaded it and confirmed it is what I uploaded. Do you still need me to upload another copy?


Posted by Microsoft on 10/31/2011 at 10:02 AM

Thankyou for this bug report.

The Intel machines mentioned in the AMD whitepaper date back to 2006, so they are likely to still be in use.

Your report mentions an attachment, which repros the problem, but I cannot see that attachment. Could you re-attach, please?

Meantime, I'll go check the reasons for our emitting those vendor-specific PREFETCH instructions.


Jim Hogg
Posted by MS-Moderator07 [Feedback Moderator] on 10/31/2011 at 12:19 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Posted by MS-Moderator01 on 10/28/2011 at 11:47 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(