[llvm-dev] Way to guarantee generated indirect call is via memory?
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Fri Aug 21 09:38:02 PDT 2015
The two options listed so far (inline asm and patchable code via
patchpoints/statepoints) are definitely your best options if the call
via memory is a functional requirement.
If you're willing to live with some chance LLVM emits different code,
you could try representing the function pointer as an external global
variable in the Module with the call and then linking it with a Module
which contains the constant value of the global. My guess - haven't
checked - is that this would generally result in the code generation you
want. This would mostly be useful for an experiment or an optimization,
not for fulfilling a functional or ABI requirement.
On 08/21/2015 09:28 AM, John Criswell via llvm-dev wrote:
> Dear Eugene,
> I think the best way to do this is to generate inline assembly code at
> the LLVM IR level that uses the memory-based addressing mode that you
> want. Any other approach could break with changes/enhancements to the
> LLVM code generator.
> The only other way to do this is to write an LLVM MachineFunctionPass,
> but that is probably overkill for what you're trying to do.
> John Criswell
> On 8/17/15 6:41 PM, Eugene Rozenfeld via llvm-dev wrote:
>> I’d like to generate an indirect call instruction that will end up as
>> a call via memory and not register.
>> The address of the target is a constant.
>> For example, something like
>> %25 = load i64, i64* @get_Now
>> %26 = inttoptr i64 %25 to i64 ()*
>> %27 = call i64 %26()
>> may end up as
>> mov rsi,qword ptr [00007FF658381070]
>> call rsi
>> or as
>> call qword ptr [00007FF658381070]
>> If I want to guarantee that the second form is always used, how would
>> I go about that?
>> One possibility is to use patchpoints
>> (http://llvm.org/docs/StackMaps.html#id9). Are there any other
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org http://llvm.cs.uiuc.edu
> John Criswell
> Assistant Professor
> Department of Computer Science, University of Rochester
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev