Eugene Rozenfeld via llvm-dev
2015-Aug-17 23:41 UTC
[llvm-dev] Way to guarantee generated indirect call is via memory?
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 alternatives? Eugene -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150817/09ead439/attachment-0001.html>
Sanjoy Das via llvm-dev
2015-Aug-17 23:47 UTC
[llvm-dev] Way to guarantee generated indirect call is via memory?
> One possibility is to use patchpoints > (http://llvm.org/docs/StackMaps.html#id9). Are there any other alternatives?Have you tried using a small code model? -- Sanjoy
Eugene Rozenfeld via llvm-dev
2015-Aug-18 02:05 UTC
[llvm-dev] Way to guarantee generated indirect call is via memory?
Yes, I tried small code model. It does help some but still doesn't guarantee that optimizations won't decide to hoist the address into a register. Eugene -----Original Message----- From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com] Sent: Monday, August 17, 2015 4:48 PM To: Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com> Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Way to guarantee generated indirect call is via memory?> One possibility is to use patchpoints > (https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fllvm.org%2fdocs%2fStackMaps.html%23id9&data=01%7c01%7cEugene.Rozenfeld%40microsoft.com%7c85541bfb31834041a92e08d2a75e4f5b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ThCQ46133HVAGtGsRGgAwtl%2b0pDYeFP9KlhYdVmBWog%3d). Are there any other alternatives?Have you tried using a small code model? -- Sanjoy
John Criswell via llvm-dev
2015-Aug-21 16:28 UTC
[llvm-dev] Way to guarantee generated indirect call is via memory?
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. Regards, 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 > alternatives? > > Eugene > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org http://llvm.cs.uiuc.edu > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- John Criswell Assistant Professor Department of Computer Science, University of Rochester http://www.cs.rochester.edu/u/criswell -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150821/990b4f6c/attachment.html>
Philip Reames via llvm-dev
2015-Aug-21 16:38 UTC
[llvm-dev] Way to guarantee generated indirect call is via memory?
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. Philip 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. > > Regards, > > 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 >> alternatives? >> >> Eugene >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org http://llvm.cs.uiuc.edu >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > -- > John Criswell > Assistant Professor > Department of Computer Science, University of Rochester > http://www.cs.rochester.edu/u/criswell > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150821/02174705/attachment.html>