On Thu, Nov 8, 2012 at 1:34 AM, Anitha Boyapati <span dir="ltr"><<a href="mailto:anitha.boyapati@gmail.com" target="_blank">anitha.boyapati@gmail.com</a>></span> wrote:<br><div><div class="gmail_quote">...<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I actually have confusion in mapping the role of vex_w during<br>
instruction selection. For the moment, lets just consider vex_w and<br>
not memop.<br>
<br>
[1]. What does " def rr : FMA4<>, VEX_W" mean? As per tablegen<br>
description, "rr" now inherits FMA4 and VEX_W. However VEX_W is not a<br>
class, it is an enumerated value.<br>
<br></blockquote><div><br></div><div>VEX_W is a class, which sets the VEX.W bit to 1.</div><div><br></div><div>> class VEX_W  { bit hasVEX_WPrefix = 1; }</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

[2].  How does vex_w help in instruction selection in-addition to FMA4 class?<br></blockquote><div><br></div><div>The VEX prefix is part of the instruction encoding. The VEX.W bit modifies the instruction to allow a memory address as a particular source operand, depending on ModRM. The Intel AVX reference calls this "source operand swizzling".</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[3]. Why does only "rr" and "rm"  forms have vex_w but not "mr" ?<br></blockquote><div><br></div><div>In order to accept a memory address as the second source operand, the VEX.W bit must not be set. To accept a memory address as the third source operand, the VEX.W bit must be set. The VEX.W bit is of no consequence when all operands are from registers. </div>
<div><br></div><div>-Cameron</div></div></div>