<div>Chris,</div><div><br></div><div>I'm not sure. It depends on whether the immediate value is considered relative or absolute. The actual IA-32 CALL instruction's immediate is a PC relative value. From this perspective, call with immediate N would translate into "call PC+N". This matches the present behavior.</div>
<div><br></div><div>However, the only time CALLpcrel32 gets an immediate operand is when this pattern is matched:</div><div><div><br></div><div>def : Pat<(X86call (i32 imm:$dst)),</div><div>          (CALLpcrel32 imm:$dst)>, Requires<[CallImmAddr]>;</div>
</div><div><br></div><div>The intent of this pattern is to have $dst be an absolute address.</div><div><br></div><div>Substituting an MCConstantExpr was a convenient way to express this, since the result of an expression is considered absolute.</div>
<div><br></div><div>Alternatively, I could change X86MCCodeEmitter::EmitImmediate(), so that immediate operands can generate fixups. (I'd still have to generate an MCConstantExpr for the value, since fixups track expressions).</div>
<div><br></div><div>Do you think this would be better?</div><div><br></div><div>Thanks,</div><div>- David Meyer</div><div><br></div><div><br></div><div><br></div><br><div class="gmail_quote">On Sat, Nov 20, 2010 at 9:55 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
On Nov 20, 2010, at 6:09 PM, David Meyer wrote:<br>
<br>
> Rafael,<br>
><br>
> Patch attached. Fixes the bug in .bc -> .o emission of CALLpcrel32 with absolute address.<br>
<br>
</div>I don't think that this is the right patch.  An imm operand should always be the same as an MCExpr with an imm as its value.  Perhaps the encoding code needs to be generalized to handle both forms?<br>
<font color="#888888"><br>
-Chris<br>
<br>
</font></blockquote></div><br>