llvm dev - Feb 2016 - distinguish program and temporary variables

I'm writing a pass that eliminates some variables. To show the effect of
the pass i need to show that I deleted the variables that originally appear
in the user code, not temporary variables added by llvm.

On Mon, Feb 8, 2016 at 5:59 PM, Mehdi Amini <mehdi.amini at apple.com>
wrote:
>
> > On Feb 8, 2016, at 6:39 AM, Mohammad Norouzi via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> >
> > Hi,
> >
> > I need to check if a variable belongs to the program originally.
> Consider the following code line:
> >
> > y = x + 4
> >
> > and its corresponding llvm ir (roughly):
> >
> > %16 = load i32 %x
> > %add = add i32 %16, i32 4
> > store i32 %add, %y
> >
> > I need to distinguish between %16, %add and %x, %y.
>
>
> This look like it will quickly degrades with optimization to a point where
> it won't be meaningful.
> Why are you needing this? What are you trying to accomplish?
>
> --
> Mehdi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160208/a6e4aa43/attachment.html>

> On Feb 8, 2016, at 9:17 AM, Mohammad Norouzi <mnmomn at gmail.com>
wrote:
> 
> I'm writing a pass that eliminates some variables.
Why?

The notion of a "variable from the user code" is meaningless after the
minimal amount of optimizations.

For example:

int foo(int a, int b) {
  int c = a + 1;
  int d = b + 2;
  return c + d;
}

Just running mem2reg and reassociate leads to:

; Function Attrs: nounwind ssp uwtable
define i32 @_Z3fooii(i32 %a, i32 %b) #0 !dbg !4 {
entry:
  call void @llvm.dbg.value(metadata i32 %a, i64 0, metadata !12, metadata !13),
!dbg !14
  call void @llvm.dbg.value(metadata i32 %b, i64 0, metadata !15, metadata !13),
!dbg !16
  call void @llvm.dbg.value(metadata i32 %add, i64 0, metadata !17, metadata
!13), !dbg !18
  call void @llvm.dbg.value(metadata !2, i64 0, metadata !19, metadata !13),
!dbg !20
  %add = add i32 %a, 3, !dbg !21
  %add2 = add i32 %add, %b, !dbg !22
  ret i32 %add2, !dbg !23
}


You still have two values (%add and %add2) but they don't really match any
source variable.
The first %add is still attached to a llvm.dbg.value, but not %add2.

And this is just a very simple example, with only one transformation (beside
mem2reg).

-- 
Mehdi


> To show the effect of the pass i need to show that I deleted the variables
that originally appear in the user code, not temporary variables added by llvm.
> 
> On Mon, Feb 8, 2016 at 5:59 PM, Mehdi Amini <mehdi.amini at apple.com
<mailto:mehdi.amini at apple.com>> wrote:
> 
> > On Feb 8, 2016, at 6:39 AM, Mohammad Norouzi via llvm-dev <llvm-dev
at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >
> > Hi,
> >
> > I need to check if a variable belongs to the program originally.
Consider the following code line:
> >
> > y = x + 4
> >
> > and its corresponding llvm ir (roughly):
> >
> > %16 = load i32 %x
> > %add = add i32 %16, i32 4
> > store i32 %add, %y
> >
> > I need to distinguish between %16, %add and %x, %y.
> 
> 
> This look like it will quickly degrades with optimization to a point where
it won't be meaningful.
> Why are you needing this? What are you trying to accomplish?
> 
> --
> Mehdi
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160208/1b0084b7/attachment.html>

That REALLY sounds like something that should be done at an earlier stage
in the compilation - at LLVM level, you can't really know whether something
was produced by the compiler itself, or as a consequence of something in
the source code.

Unless there is some very specific pattern to those varibles (e.g. "they
are always called XYZ_abc_kerflunk_billy_bob_*" - it is unlikely that the
compiler will call a generated variable that).

--
Mats

On 8 February 2016 at 17:17, Mohammad Norouzi via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I'm writing a pass that eliminates some variables. To show the effect
of
> the pass i need to show that I deleted the variables that originally appear
> in the user code, not temporary variables added by llvm.
>
> On Mon, Feb 8, 2016 at 5:59 PM, Mehdi Amini <mehdi.amini at
apple.com> wrote:
>
>>
>> > On Feb 8, 2016, at 6:39 AM, Mohammad Norouzi via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>> >
>> > Hi,
>> >
>> > I need to check if a variable belongs to the program originally.
>> Consider the following code line:
>> >
>> > y = x + 4
>> >
>> > and its corresponding llvm ir (roughly):
>> >
>> > %16 = load i32 %x
>> > %add = add i32 %16, i32 4
>> > store i32 %add, %y
>> >
>> > I need to distinguish between %16, %add and %x, %y.
>>
>>
>> This look like it will quickly degrades with optimization to a point
>> where it won't be meaningful.
>> Why are you needing this? What are you trying to accomplish?
>>
>> --
>> Mehdi
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160208/270a871a/attachment.html>

On Mon, Feb 8, 2016 at 6:36 PM, mats petersson <mats at planetcatfish.com>
wrote:
> That REALLY sounds like something that should be done at an earlier stage
> in the compilation - at LLVM level, you can't really know whether
something
> was produced by the compiler itself, or as a consequence of something in
> the source code.
>
I guess the compiler should know about it. It is inserting these new
variables into the ir code. And the pattern for temporary variables in llvm
is somehow instruction-dependent, e.g. "add" instructions have
temporary
variables like %add, %add2 etc.

>
> Unless there is some very specific pattern to those varibles (e.g.
"they
> are always called XYZ_abc_kerflunk_billy_bob_*" - it is unlikely that
the
> compiler will call a generated variable that).
>
Best,
Mohammad
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160208/3728e0b0/attachment.html>