[LLVMdev] LoadInst result

Amara Emerson amara.emerson at gmail.com
Mon Feb 3 03:15:28 PST 2014


You can use the LLVM custom RTTI implementation to distinguish between
different kinds of Value using dyn_cast<>, isa<>. See
http://llvm.org/docs/ProgrammersManual.html#the-isa-cast-and-dyn-cast-templates

As Tim said, Values exist before regalloc. When you see a reference
like %foo in the IR, it's a reference to the Value, not the actual
virtual register.

Amara

On 3 February 2014 10:19,  <nizam at cse.iitm.ac.in> wrote:
> Hi Tim,
>
> Assume a store instruction. Store has 2 Operands. I can use the
> store->getOperand(0) and store->getOperand(1) methods to access these
> operands in form of Value *.
>
> Very likely that the operands are stack variables or formal variables or
> global variables. It is also possible that these operands are LLVM
> virtual-registers. Is there a way to determine if a given operand is a
> virtual-register or memory-related-on.
>
> I hope this clarifies my question.
> BR/Nizam
>
>
> ________________________________
> From: "Tim Northover" <t.p.northover at gmail.com>
> To: nizam at cse.iitm.ac.in
> Cc: "Sean Silva" <chisophugis at gmail.com>, "llvmdev" <llvmdev at cs.uiuc.edu>
> Sent: Monday, February 3, 2014 3:42:29 PM
>
> Subject: Re: [LLVMdev] LoadInst result
>
> Hi Nizam,
>
>> Is there a simple way to check if a given instruction operand (represented
>> by Value *) is a virtual register or otherwise? Context: I am creating a
>> ModulePass for pointer Analysis.
>
> Values exist before any distinction is made between virtual and
> physical registers (they only get introduced after or, in rare cases
> at lowering to MachineInstrs). Or did you mean some distinction other
> than virtual/physical? What would you expect the Value to be if it's
> not a virtual register?
>
> Cheers.
>
> Tim.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>



More information about the llvm-dev mailing list