[llvm-dev] How to create and insert a call MachineInstr?

Will Lester via llvm-dev llvm-dev at lists.llvm.org
Mon Apr 16 22:24:38 PDT 2018


Hi Tim,
I'm sorry to bother you again. Since I have met the problem, how to check
used registers and avoid clobbering live registers, which you mentioned in
the email.
I am working in the function X86InstrInfo::storeRegToStackSlot, which is in
lib/Target/X86/X86InstrInfo.cpp.
And I have an extra problem, may I use MOV64mr and two addReg to set two
registers as its arguments? I want to use content of one register as the
address to be stored, and content of the other register as the source.

Thanks a lot!
Will

2018-04-13 22:11 GMT+08:00 Will Lester <hslester96 at gmail.com>:

> Thanks for your help! I'm much more clear about this problem.
> Will
>
> 2018-04-13 17:53 GMT+08:00 Tim Northover <t.p.northover at gmail.com>:
>
>> Hi Will,
>>
>> On 13 April 2018 at 09:50, Will Lester via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> > I have used BuildMI to build a MachineInstr. But it seems that a call
>> > MachineInstr only has one parameter which is a
>> > register(%physreg44<imp-use>?).
>>
>> This depends on the target, but calls normally have a few operands:
>>
>>   + The callee (a register or a global address or something).
>>   + A regmask indicating which registers the call preserves.
>>   + A list of imp-uses and imp-defs for the registers used to pass and
>> return parameters.
>>
>> If you writie a .ll file that makes a call you should be able to see
>> all these components in the generated MIR.
>>
>> > Therefore how can I set the callee function and the arguments of the
>> function?
>>
>> For a direct call, you'd normally use MachineInstrBuilder's
>> addGlobalAddress to set the callee. You have to emit separate moves
>> and stores before the call to put the arguments in the correct
>> registers and stack slots. Be careful not to clobber live registers!
>>
>> We can probably give a few more details (like the call instruction to
>> use, and which registers pass parameters; maybe some extra quirks) if
>> we know the actual target you're compiling for, but the outline above
>> won't change significantly.
>>
>> Cheers.
>>
>> Tim.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180417/e07edd32/attachment.html>


More information about the llvm-dev mailing list