llvm dev - Nov 2018 - Convert Register Names to String

Hi Tim,
Thanks for the nice answer. The code that you mentioned, seems to generate
the IR. You mean I should reuse the code to extract and output the register
names in a file. Next, I should postprocess the file in my own pass?
Regards.

On Mon, 12 Nov 2018 at 13:09, Tim Northover <t.p.northover at gmail.com>
wrote:
> Hi Ahmad,
>
> On Sun, 11 Nov 2018 at 13:39, Ahmad Nouralizadeh Khorrami via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > I want to do a cutomized points-to analysis on IR. Suppose that we
have:
> > %91 = bitcast i8* %90 to %struct.demux_packet*, !dbg !2688
> >
> > I want to store sth similar to %91 -> target of %90, which records
the
> target of pointer named %91. How can I access the names (Here, %90 and
%91)?
>
> Unfortunately it's not trivial. You can see the logic used in
> AssemblyWriter::printInstruction (in lib/IR/AsmWriter.cpp).
>
> It boils down to using Instruction::getName if it exists, otherwise
> there's a special class called ModuleSlotTracker (the
"Machine"
> instance in that function) that gives each unnamed value a number.
> You'd have to create one of those yourself; I had a quick look at the
> header and it actually seems pretty easy to use, which was a pleasant
> surprise.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181112/e44dfc8c/attachment.html>

Hi Ahmad,

On Mon, 12 Nov 2018 at 12:25, Ahmad Nouralizadeh Khorrami
<ahmad.llvm at gmail.com> wrote:
> Thanks for the nice answer. The code that you mentioned, seems to generate
the IR. You mean I should reuse the code to extract and output the register
names in a file. Next, I should postprocess the file in my own pass?
Sorry, I assumed you'd already decided to do that to generate data for
an external program and needed it in IR form.

If the external program bit is true but not the tight coupling to LLVM
IR you could probably just use the Value* pointers as the "name" of a
value.

If everything is going to be happening in LLVM then you have other
options. Again the most likely solution would be to store pointers to
Values and forget about names. I think the whole "Analysis" library of
LLVM is dedicated to providing data in roughly that format to passes
that actually interpret it, so you should be able to write one that
provides some kind of simple mapping from "Value *" to "Value
*" as
its interface. Then a transformation pass could make use of that data.

That transformation pass might even be one that embeds the information
into the Module (say, as a set of global variables providing metadata)
for much later consumption.

Cheers.

Tim.

Thanks Tim. So, you mean name information is redundant and I can use
Value*, instead. I will try to use that approach.
Regards.

On Mon, 12 Nov 2018 at 16:07, Tim Northover <t.p.northover at gmail.com>
wrote:
> Hi Ahmad,
>
> On Mon, 12 Nov 2018 at 12:25, Ahmad Nouralizadeh Khorrami
> <ahmad.llvm at gmail.com> wrote:
> > Thanks for the nice answer. The code that you mentioned, seems to
> generate the IR. You mean I should reuse the code to extract and output the
> register names in a file. Next, I should postprocess the file in my own
> pass?
>
> Sorry, I assumed you'd already decided to do that to generate data for
> an external program and needed it in IR form.
>
> If the external program bit is true but not the tight coupling to LLVM
> IR you could probably just use the Value* pointers as the "name"
of a
> value.
>
> If everything is going to be happening in LLVM then you have other
> options. Again the most likely solution would be to store pointers to
> Values and forget about names. I think the whole "Analysis"
library of
> LLVM is dedicated to providing data in roughly that format to passes
> that actually interpret it, so you should be able to write one that
> provides some kind of simple mapping from "Value *" to
"Value *" as
> its interface. Then a transformation pass could make use of that data.
>
> That transformation pass might even be one that embeds the information
> into the Module (say, as a set of global variables providing metadata)
> for much later consumption.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20181112/31ee7c23/attachment.html>