alloca & store generation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

alloca & store generation

Ryan M. Lefever
I am writing a transformation that needs to add a call to a function F()
at the beginning of main() with the addresses of argc and argv as
parameters to F().  However, the bytecode file I'm transforming has not
allocated space on the stack for argc and argv.  So, I developed my
transformation to change main() from:

-----
int main(int %argc, sbyte** %argv){
entry:
   ...
   // some use of %argc and %argv
   ...
}
-----

to the following code:

-----
int main(int %argc, sbyte** %argv){
entry:
   %argc_addr = alloca int
   %argv_addr = alloca sbyte**
   store int %argc, int* %argc_addr
   store sbyte** %argv, sbyte*** %argv_addr
   call void %F ( int %argc_addr, sbyte*** %argv_addr )
   %tmp = load int* %argc_addr
   %tmp1 = load int* %tmp
   ...
   // the use of %argc and %argv is transformed to use
   // %tmp and %tmp1, respectively
   ...
}
-----

However, after adding the alloca and stores, I print out main it looks like:

-----
int %main(int %argc, sbyte** %argv) {
entry:
   alloca int              ; <int*>:0 [#uses=1]
   alloca sbyte**          ; <sbyte***>:0 [#uses=1]
   store int %argc, int* %0
   store sbyte** %argv, sbyte*** %0
   ...
-----

I used the following code in my transformation:

-----
   BasicBlock* eb = M.getMainFunction()->getEntryBlock();
   Function::arg_iterator argc_it = mainfun->arg_begin();
   Function::arg_iterator argv_it = argc_it;
   ++argv_it;
   Argument* argc = &*argc_it;
   Argument* argv = &*argv_it;
   Instruction* insertNewInstsBefore = &eb->front();
   AllocaInst* argc_alloca = new AllocaInst(argc->getType(), "",
                                           insertNewInstsBefore);
   AllocaInst* argv_alloca = new AllocaInst(argv->getType(), "",
                                           insertNewInstsBefore);
   new StoreInst(argc, argc_alloca, false, insertNewInstsBefore);
   new StoreInst(argv, argv_alloca, false, insertNewInstsBefore);
-----

Why isn't llvm giving a name to the value returned by the allocas and
using it in the store instructions?

Regards,
Ryan
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: alloca & store generation

Ryan M. Lefever
After looking at this problem longer, I believe that there is something
wrong with the disassembler.  When I run my transformation and then
disassemble the output, I get bytecode that looks like:

-----
int %main(int %argc, sbyte** %argv) {
entry:
         alloca int              ; <int*>:0 [#uses=3]
         alloca sbyte**          ; <sbyte***>:0 [#uses=3]
         store int %argc, int* %0
         store sbyte** %argv, sbyte*** %0
         call void %F( int* %0, sbyte*** %0, int 1, int 0 )
-----

However, if I use llc to generate C code from the bytecode that my
transformation produces, it looks like:

-----
int main(int ltmp_75_3, signed char **ltmp_76_9) {
   int ltmp_3355_85;    /* Address-exposed local */
   signed char **ltmp_3356_105;    /* Address-exposed local */
   ...
   *(&ltmp_3355_85) = ltmp_75_3;
   *(&ltmp_3356_105) = ltmp_76_9;
   initLogging((&ltmp_3355_85), (&ltmp_3356_105), 1, 0);
-----

The C code is what I intended.  That leaves me to believe that my
transformation produced the correct bytecode, but the dissassembler is
not properly disassebling the bytecode.

Ryan


Ryan M. Lefever wrote:

> I am writing a transformation that needs to add a call to a function F()
> at the beginning of main() with the addresses of argc and argv as
> parameters to F().  However, the bytecode file I'm transforming has not
> allocated space on the stack for argc and argv.  So, I developed my
> transformation to change main() from:
>
> -----
> int main(int %argc, sbyte** %argv){
> entry:
>    ...
>    // some use of %argc and %argv
>    ...
> }
> -----
>
> to the following code:
>
> -----
> int main(int %argc, sbyte** %argv){
> entry:
>    %argc_addr = alloca int
>    %argv_addr = alloca sbyte**
>    store int %argc, int* %argc_addr
>    store sbyte** %argv, sbyte*** %argv_addr
>    call void %F ( int %argc_addr, sbyte*** %argv_addr )
>    %tmp = load int* %argc_addr
>    %tmp1 = load int* %tmp
>    ...
>    // the use of %argc and %argv is transformed to use
>    // %tmp and %tmp1, respectively
>    ...
> }
> -----
>
> However, after adding the alloca and stores, I print out main it looks like:
>
> -----
> int %main(int %argc, sbyte** %argv) {
> entry:
>    alloca int              ; <int*>:0 [#uses=1]
>    alloca sbyte**          ; <sbyte***>:0 [#uses=1]
>    store int %argc, int* %0
>    store sbyte** %argv, sbyte*** %0
>    ...
> -----
>
> I used the following code in my transformation:
>
> -----
>    BasicBlock* eb = M.getMainFunction()->getEntryBlock();
>    Function::arg_iterator argc_it = mainfun->arg_begin();
>    Function::arg_iterator argv_it = argc_it;
>    ++argv_it;
>    Argument* argc = &*argc_it;
>    Argument* argv = &*argv_it;
>    Instruction* insertNewInstsBefore = &eb->front();
>    AllocaInst* argc_alloca = new AllocaInst(argc->getType(), "",
>   insertNewInstsBefore);
>    AllocaInst* argv_alloca = new AllocaInst(argv->getType(), "",
>   insertNewInstsBefore);
>    new StoreInst(argc, argc_alloca, false, insertNewInstsBefore);
>    new StoreInst(argv, argv_alloca, false, insertNewInstsBefore);
> -----
>
> Why isn't llvm giving a name to the value returned by the allocas and
> using it in the store instructions?
>
> Regards,
> Ryan
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

--
Ryan M. Lefever  [http://www.ews.uiuc.edu/~lefever]
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: alloca & store generation

Andreas Eriksson
In reply to this post by Ryan M. Lefever
> Why isn't llvm giving a name to the value returned by the allocas and
> using it in the store instructions?
Because you pass in an empty string for the name in the new AllocaInst
calls below. Replace the empty strings with "argc_addr" or whatever
you want.

>    AllocaInst* argc_alloca = new AllocaInst(argc->getType(), "",
>                                            insertNewInstsBefore);
>    AllocaInst* argv_alloca = new AllocaInst(argv->getType(), "",
>                                            insertNewInstsBefore);
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: alloca & store generation

Ryan M. Lefever
It seems as though, when the bytecode is disassebled, the result of the
allocas should be given as a parameter to the stores.  If the
disassembler doesn't give the allocas a name, then that dependency is
not conveyed.

Andreas Eriksson wrote:

>>Why isn't llvm giving a name to the value returned by the allocas and
>>using it in the store instructions?
>
> Because you pass in an empty string for the name in the new AllocaInst
> calls below. Replace the empty strings with "argc_addr" or whatever
> you want.
>
>
>>   AllocaInst* argc_alloca = new AllocaInst(argc->getType(), "",
>>                                           insertNewInstsBefore);
>>   AllocaInst* argv_alloca = new AllocaInst(argv->getType(), "",
>>                                           insertNewInstsBefore);
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

--
Ryan M. Lefever  [http://www.ews.uiuc.edu/~lefever]
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: alloca & store generation

Anton Korobeynikov
In reply to this post by Andreas Eriksson
Hello, Ryan.

> It seems as though, when the bytecode is disassebled, the result of the
> allocas should be given as a parameter to the stores.
It's given.

>  If the disassembler doesn't give the allocas a name, then that dependency is
> not conveyed.
Both disassembly & bytecode is correct. Please carefully read LLVM
Language reference about %"num" names.

--
With best regards, Anton Korobeynikov.

Faculty of Mathematics & Mechanics, Saint Petersburg State University.


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: alloca & store generation

John Criswell
In reply to this post by Ryan M. Lefever
Ryan M. Lefever wrote:

> After looking at this problem longer, I believe that there is something
> wrong with the disassembler.  When I run my transformation and then
> disassemble the output, I get bytecode that looks like:
>
> -----
> int %main(int %argc, sbyte** %argv) {
> entry:
>          alloca int              ; <int*>:0 [#uses=3]
>          alloca sbyte**          ; <sbyte***>:0 [#uses=3]
>          store int %argc, int* %0
>          store sbyte** %argv, sbyte*** %0
>          call void %F( int* %0, sbyte*** %0, int 1, int 0 )
>  

I believe the above bytecode is correct.  When an instruction is not
given a name, the compiler assigns it a numeric name.  Names are unique
to type (for versions of LLVM <= 1.9), so your first two alloca
instructions are named %0 and could be re-written as follows:

%0 = alloca int
%0 = alloca sbyte **

Hence, the store and call instruction are using the alloca'ed pointers
as intended.

It would probably be nice if the disassembler listed those default
assigned names explicitly.  There might be a good motivation for why it
doesn't, but if there is, I don't know the reason.

-- John T.

> -----
>
> However, if I use llc to generate C code from the bytecode that my
> transformation produces, it looks like:
>
> -----
> int main(int ltmp_75_3, signed char **ltmp_76_9) {
>    int ltmp_3355_85;    /* Address-exposed local */
>    signed char **ltmp_3356_105;    /* Address-exposed local */
>    ...
>    *(&ltmp_3355_85) = ltmp_75_3;
>    *(&ltmp_3356_105) = ltmp_76_9;
>    initLogging((&ltmp_3355_85), (&ltmp_3356_105), 1, 0);
> -----
>
> The C code is what I intended.  That leaves me to believe that my
> transformation produced the correct bytecode, but the dissassembler is
> not properly disassebling the bytecode.
>
> Ryan
>
>
> Ryan M. Lefever wrote:
>  
>> I am writing a transformation that needs to add a call to a function F()
>> at the beginning of main() with the addresses of argc and argv as
>> parameters to F().  However, the bytecode file I'm transforming has not
>> allocated space on the stack for argc and argv.  So, I developed my
>> transformation to change main() from:
>>
>> -----
>> int main(int %argc, sbyte** %argv){
>> entry:
>>    ...
>>    // some use of %argc and %argv
>>    ...
>> }
>> -----
>>
>> to the following code:
>>
>> -----
>> int main(int %argc, sbyte** %argv){
>> entry:
>>    %argc_addr = alloca int
>>    %argv_addr = alloca sbyte**
>>    store int %argc, int* %argc_addr
>>    store sbyte** %argv, sbyte*** %argv_addr
>>    call void %F ( int %argc_addr, sbyte*** %argv_addr )
>>    %tmp = load int* %argc_addr
>>    %tmp1 = load int* %tmp
>>    ...
>>    // the use of %argc and %argv is transformed to use
>>    // %tmp and %tmp1, respectively
>>    ...
>> }
>> -----
>>
>> However, after adding the alloca and stores, I print out main it looks like:
>>
>> -----
>> int %main(int %argc, sbyte** %argv) {
>> entry:
>>    alloca int              ; <int*>:0 [#uses=1]
>>    alloca sbyte**          ; <sbyte***>:0 [#uses=1]
>>    store int %argc, int* %0
>>    store sbyte** %argv, sbyte*** %0
>>    ...
>> -----
>>
>> I used the following code in my transformation:
>>
>> -----
>>    BasicBlock* eb = M.getMainFunction()->getEntryBlock();
>>    Function::arg_iterator argc_it = mainfun->arg_begin();
>>    Function::arg_iterator argv_it = argc_it;
>>    ++argv_it;
>>    Argument* argc = &*argc_it;
>>    Argument* argv = &*argv_it;
>>    Instruction* insertNewInstsBefore = &eb->front();
>>    AllocaInst* argc_alloca = new AllocaInst(argc->getType(), "",
>>   insertNewInstsBefore);
>>    AllocaInst* argv_alloca = new AllocaInst(argv->getType(), "",
>>   insertNewInstsBefore);
>>    new StoreInst(argc, argc_alloca, false, insertNewInstsBefore);
>>    new StoreInst(argv, argv_alloca, false, insertNewInstsBefore);
>> -----
>>
>> Why isn't llvm giving a name to the value returned by the allocas and
>> using it in the store instructions?
>>
>> Regards,
>> Ryan
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>    
>
>  

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: alloca & store generation

Ryan M. Lefever
In reply to this post by Anton Korobeynikov
Thanks for the help.  I apparently missed the part in the documentation
about %"num" names.

Anton Korobeynikov wrote:

> Hello, Ryan.
>
>> It seems as though, when the bytecode is disassebled, the result of the
>> allocas should be given as a parameter to the stores.
> It's given.
>
>>  If the disassembler doesn't give the allocas a name, then that dependency is
>> not conveyed.
> Both disassembly & bytecode is correct. Please carefully read LLVM
> Language reference about %"num" names.
>

--
Ryan M. Lefever  [http://www.ews.uiuc.edu/~lefever]

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev