[llvm-dev] Spare Register at one Machine Instruction

Hong Hu via llvm-dev llvm-dev at lists.llvm.org
Sat Jan 21 01:21:52 PST 2017


Hi Nemanja and Matthias,

Thanks for the reply.

I checked both Register Scavenger and LivePhysReg. It seems that both work
on the BasicBlock level, right?

Is it possible to perform such analysis in a whole function? For example,
considering the calling convention (where the rsi, rdi will be in use from
the beginning) and the return convention (where rax will be in use in the
last bb).

Regards,
Hu Hong

On 20 January 2017 at 03:55, Matthias Braun <mbraun at apple.com> wrote:

> There is also the LivePhysReg facility that I would recomment if you just
> want to query for a free register and do not need the full feature set of
> the RegisterScavenger.
>
> - Matthias
>
> On Jan 19, 2017, at 5:50 AM, Nemanja Ivanovic via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> I believe what you're after is the register scavenger.
> It's in: include/llvm/CodeGen/RegisterScavenging.h
> Implementation: lib/CodeGen/RegisterScavenging.cpp
>
> On Thu, Jan 19, 2017 at 1:36 PM, Hong Hu via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi All,
>>
>> Given a machine instruction, is it possible to tell which register(s) is
>> still not in use?
>>
>> For example, given one instruction A, if the one follows it (say B)
>> defines register rax, then I can tell rax should spare at instruction A.
>>
>> The purpose is to use the spare register to replace registers used by A,
>> for instrumentation purpose.
>>
>> Regards,
>> Hu Hong
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
> _______________________________________________
> 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/20170121/def1e1dd/attachment.html>


More information about the llvm-dev mailing list