[llvm-dev] (no subject)

Doerfert, Johannes Rudolf via llvm-dev llvm-dev at lists.llvm.org
Sat Jan 26 16:52:22 PST 2019


On 01/26, Alberto Barbaro via llvm-dev wrote:
> Hi,
> thanks for your answer
> 
> Il giorno ven 25 gen 2019 alle ore 06:23 Doerfert, Johannes Rudolf <
> jdoerfert at anl.gov> ha scritto:
> 
> > On 01/20, Alberto Barbaro via llvm-dev wrote:
> > > Hi all,
> > > I have the following C code:
> > >
> > > #include<stdio.h>
> > >
> > > int main(int argc, char *argv[]) {
> > >
> > >     printf("%s\n", argv[0]);
> > >     return argc;
> > > }
> > >
> > > that generates the following IR for the main function:
> > >
> > > ; Function Attrs: noinline nounwind optnone uwtable
> > > define i32 @main(i32, i8**) #0 {
> > >   %3 = alloca i32, align 4
> > >   %4 = alloca i32, align 4
> > >   %5 = alloca i8**, align 8
> > >   store i32 0, i32* %3, align 4
> > >   store i32 %0, i32* %4, align 4
> > >   store i8** %1, i8*** %5, align 8
> > >   %6 = load i8**, i8*** %5, align 8
> > >   %7 = getelementptr inbounds i8*, i8** %6, i64 0
> > >   %8 = load i8*, i8** %7, align 8
> > >   %9 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([4 x i8],
> > [4
> > > x i8]* @.str, i32 0, i32 0), i8* %8)
> > >   %10 = load i32, i32* %4, align 4
> > >   ret i32 %10
> > > }
> >
> > You should really run -mem2reg (without the optnone though). Also
> > -instcombine is afterwards often helpful to clean up clang generated
> > code, or maybe just run it with -O1.
> >
> >
> thanks for the suggestion, I understand that the code is not clean but i'd
> like to understand how it works in general for now :)

Understanding the concept can be done either way, one is in my opinion
just unnecessarily complicated.


> > > I think %8 will contain the address of argv[0], so %7 was storing a
> > pointer
> > > to pointer to argv? I'm not sure of that.
> >
> > Let's see: argc is %0 and argv == &argv[0] is %1. The latter is stored
> > in %5, which is loaded as %6. The GEP (%7) is a no-op, thus %6 == %7.
> > Finally, %8 is the value argv[0] of type char/i8.
> >
> >
> why do you consider the GET to be a no-op? %6 is a i8** instead %i7 is an
> i8*. Thanks

This GEP computes the address of the 0th element of the "array" %6. The
result has the same address as the array and it also has the same type
so I'd say they are indistinguishable.

> > > Considering that I can access the GenericValue set by
> > > visitGetElementPtrInst. How can I obtain the value of argv[0] at runtime
> > > using the Interpreter class?
> >
> > Sorry can't help with that. I don't know the Interpreter class and I
> > guess "GenericValue" and "visitGetElementPtrInst" are somehow related to
> > it.
> >
> >
> No problem, visitGetElementPtrInst is jus that the function that is called
> when a GEP instruction is found.

It seems the function was appropriately named ;)


> I tried to get the value calling getOperandValue and basically
> reproducing the usual LLVM behavior but i always have 0 as value.

What do you think "the usual LLVM behavior is"? Also consider that GEPs
can have multiple operands. What exactly do you want to achieve anyway?


> Maybe a stupid question but when I see the PointerVal of a pointer
> (e.g. 0x2281a30 ), if I read the bytes as that specific address would
> I find the value or LLVM does not really store any value in there and
> the address is just some sort of index within a "emulated" memory?

I'm not sure I understand what you are asking but I'm pretty sure you
will not.


> > > Thanks
> >
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > llvm-dev at lists.llvm.org
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
> >
> > --
> >
> > Johannes Doerfert
> > Researcher
> >
> > Argonne National Laboratory
> > Lemont, IL 60439, USA
> >
> > jdoerfert at anl.gov
> 
> 
> Thanks

> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-- 

Johannes Doerfert
Researcher

Argonne National Laboratory
Lemont, IL 60439, USA

jdoerfert at anl.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190127/191250d5/attachment.sig>


More information about the llvm-dev mailing list