[llvm-dev] API to Differentiate between SSA and non SSA form

Anshuman Dhuliya via llvm-dev llvm-dev at lists.llvm.org
Wed Apr 19 09:22:19 PDT 2017

Is it the case that for each C stack variable there will always be and
'alloca' statement. If so, we can identify all such variables.

And globals can be identified separately, I guess...

Thanks & Regards
Anshuman Dhuliya
PhD Scholar
CSE Department
IIT Bombay
Mumbai, India

On Wed, Apr 19, 2017 at 9:20 PM, Pushpinder Singh <
pushpinderdhaliwal00 at gmail.com> wrote:

> Hello everyone,
> We are working on a particular points-to analysis. The final output of
> that analysis should not have the LLVM SSA temporaries (like, %0, %1).
> My doubt is that whether we can extract the normal C variables from
> LLVM IR or is there any way to differentiate between SSA temporary and
> local C variable?
> For e.g. in GCC I can check whether a particular variable is an SSA
> temporary like,
>      if(TREE_CODE(t) == SSA_NAME)
>             return true;
> Basically, I want to skip all those %0, %1 temporaries. But keep all
> those which refer to C variables. One way to do this would be to check
> whether a Value has been given a name by using hasName function. But
> it does not work every time. For e.g. in case of getelementptr
> instruction, this name refers to a member name of a structure (which
> is in SSA form).
> E.g.,
> define void @f() {
> entry:
>   %s = alloca %struct.A, align 8
>   %a = alloca i32, align 4                        ; I can know that
> this is a C variable
>   store i32 10, i32* %a, align 4
>   %b = getelementptr inbounds %struct.A, %struct.A* %s, i32 0, i32 1
>   ; but this is not
>   store i32* %a, i32** %b, align 8
>   ; and this is not a C variable, so hasName logic can not work here.
>   %a1 = getelementptr inbounds %struct.A, %struct.A* %s, i32 0, i32 0
>   store i32 30, i32* %a1, align 8
>   ret void
> }
> Thanks,
> Pushpinder Singh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170419/a0a3774d/attachment.html>

More information about the llvm-dev mailing list