SSA in the Front End

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

SSA in the Front End

Ricardo-33
Hi,

I have been looking into the code that generates the LLVM assembly in the LLVM front end, but I am
not very sure if at the time that the llvm_c_expand_body_1 function is called, the SSA form was
already constructed (each definition dominates all the uses). Can somebody please tell me?

Thanks

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

Re: SSA in the Front End

John Criswell
Ricardo wrote:
> Hi,
>
> I have been looking into the code that generates the LLVM assembly in the LLVM front end, but I am
> not very sure if at the time that the llvm_c_expand_body_1 function is called, the SSA form was
> already constructed (each definition dominates all the uses). Can somebody please tell me?

The LLVM GCC frontend does not translate variables directly into LLVM
virtual regsiters (which must be in SSA form).

Instead, the LLVM GCC frontend simply uses a memory location for each
variable (e.g. a local variable is allocated via the LLVM alloca
instruction).  If you use llvm-gcc -S -o file.ll file.c, you can see the
code that llvm-gcc generates.

Next, gccas (after assembling the LLVM assembly file) runs a pass called
mem2reg.  This pass finds memory locations that can be promoted to LLVM
virtual registers and promotes them into registers.  The following
commands will allow you to see the change:

llvm-as -o file.bc file.ll
opt -mem2reg -o newfile.bc file.bc
llvm-dis -o newfile.ll newfile.bc

If you compare newfile.ll to file.ll, you'll see what the mem2reg
transformation does.

Using this technique, language frontends don't need to worry about
maintaining SSA for variables that it generates.  It simply generates
them as memory locations and the LLVM optimizer fixes it up into more
efficient code.

-- John T.

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


--
John T. Criswell
Research Programmer
University of Illinois at Urbana-Champaign
"It's today!" said Piglet. "My favorite day," said Pooh.

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

Re: SSA in the Front End

Ricardo-33
Thanks for the explanation. It's more clear now

The only thing that seems strange is that in the function llvm_expand_shortcircuit_truth_expr in
the front end, there is the creation of a PHI instruction. If there is no SSA yet, why do you do
that?

Thanks in advance




--- John Criswell <[hidden email]> wrote:

> Ricardo wrote:
> > Hi,
> >
> > I have been looking into the code that generates the LLVM assembly in the LLVM front end, but
> I am
> > not very sure if at the time that the llvm_c_expand_body_1 function is called, the SSA form
> was
> > already constructed (each definition dominates all the uses). Can somebody please tell me?
>
> The LLVM GCC frontend does not translate variables directly into LLVM
> virtual regsiters (which must be in SSA form).
>
> Instead, the LLVM GCC frontend simply uses a memory location for each
> variable (e.g. a local variable is allocated via the LLVM alloca
> instruction).  If you use llvm-gcc -S -o file.ll file.c, you can see the
> code that llvm-gcc generates.
>
> Next, gccas (after assembling the LLVM assembly file) runs a pass called
> mem2reg.  This pass finds memory locations that can be promoted to LLVM
> virtual registers and promotes them into registers.  The following
> commands will allow you to see the change:
>
> llvm-as -o file.bc file.ll
> opt -mem2reg -o newfile.bc file.bc
> llvm-dis -o newfile.ll newfile.bc
>
> If you compare newfile.ll to file.ll, you'll see what the mem2reg
> transformation does.
>
> Using this technique, language frontends don't need to worry about
> maintaining SSA for variables that it generates.  It simply generates
> them as memory locations and the LLVM optimizer fixes it up into more
> efficient code.
>
> -- John T.
>
> >
> > Thanks
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > [hidden email]         http://llvm.cs.uiuc.edu
> > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> --
> John T. Criswell
> Research Programmer
> University of Illinois at Urbana-Champaign
> "It's today!" said Piglet. "My favorite day," said Pooh.
>
>

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

Re: SSA in the Front End

Chris Lattner
On Fri, 27 May 2005, Ricardo wrote:
> Thanks for the explanation. It's more clear now
>
> The only thing that seems strange is that in the function llvm_expand_shortcircuit_truth_expr in
> the front end, there is the creation of a PHI instruction. If there is no SSA yet, why do you do
> that?

That is just a shortcut.  We could introduce an alloca for every
shortcircuit expression, but as a minor compile time efficiency issue, we
don't.

-Chris


> --- John Criswell <[hidden email]> wrote:
>
>> Ricardo wrote:
>>> Hi,
>>>
>>> I have been looking into the code that generates the LLVM assembly in the LLVM front end, but
>> I am
>>> not very sure if at the time that the llvm_c_expand_body_1 function is called, the SSA form
>> was
>>> already constructed (each definition dominates all the uses). Can somebody please tell me?
>>
>> The LLVM GCC frontend does not translate variables directly into LLVM
>> virtual regsiters (which must be in SSA form).
>>
>> Instead, the LLVM GCC frontend simply uses a memory location for each
>> variable (e.g. a local variable is allocated via the LLVM alloca
>> instruction).  If you use llvm-gcc -S -o file.ll file.c, you can see the
>> code that llvm-gcc generates.
>>
>> Next, gccas (after assembling the LLVM assembly file) runs a pass called
>> mem2reg.  This pass finds memory locations that can be promoted to LLVM
>> virtual registers and promotes them into registers.  The following
>> commands will allow you to see the change:
>>
>> llvm-as -o file.bc file.ll
>> opt -mem2reg -o newfile.bc file.bc
>> llvm-dis -o newfile.ll newfile.bc
>>
>> If you compare newfile.ll to file.ll, you'll see what the mem2reg
>> transformation does.
>>
>> Using this technique, language frontends don't need to worry about
>> maintaining SSA for variables that it generates.  It simply generates
>> them as memory locations and the LLVM optimizer fixes it up into more
>> efficient code.
>>
>> -- John T.
>>
>>>
>>> Thanks
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> [hidden email]         http://llvm.cs.uiuc.edu
>>> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>> --
>> John T. Criswell
>> Research Programmer
>> University of Illinois at Urbana-Champaign
>> "It's today!" said Piglet. "My favorite day," said Pooh.
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-Chris

--
http://nondot.org/sabre/
http://llvm.cs.uiuc.edu/

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