[llvm-commits] [PATCH] Fix lowering of CALLpcrel32 with absolute address (PR8656)

[David Meyer]

Chris,

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.

However, the only time CALLpcrel32 gets an immediate operand is when this
pattern is matched:

def : Pat<(X86call (i32 imm:$dst)),
          (CALLpcrel32 imm:$dst)>, Requires<[CallImmAddr]>;

The intent of this pattern is to have $dst be an absolute address.

Substituting an MCConstantExpr was a convenient way to express this, since
the result of an expression is considered absolute.

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).

Do you think this would be better?

Thanks,
- David Meyer




On Sat, Nov 20, 2010 at 9:55 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Nov 20, 2010, at 6:09 PM, David Meyer wrote:
>
> > Rafael,
> >
> > Patch attached. Fixes the bug in .bc -> .o emission of CALLpcrel32 with
> absolute address.
>
> 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?
>
> -Chris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20101121/4ad7be29/attachment.html>