Page MenuHomePhabricator

[DEBUG INFO] Source correlation for lambda captured values.
AbandonedPublic

Authored by ABataev on Aug 18 2015, 9:05 PM.

Details

Summary

When variables are implicitly captured in lambdas, debug info generated for captured variables points to location where they are used first. This patch makes debug info to point to capture default location:

extern "C" int printf(const char *, ...);

template<typename F> void invoke( const F& f ) {
    f();
}

int main () {
    int apple = 0;
    int banana = 1;
    int cherry = 2;
    invoke( 

 13.       [=]{
 14.           printf("apple = %d\n",apple);
 15.           printf("banana = %d\n",banana);
 16.           printf("cherry = %d\n",cherry);
            }

     );
    return 0;
}

Clang is generating the following code for preparing the "invoke" parameter, which is the lambda:

%0 = getelementptr inbounds %class.anon, %class.anon* %ref.tmp, i32 0, i32 0, !dbg !40
%1 = load i32, i32* %apple, align 4, !dbg !41
store i32 %1, i32* %0, align 4, !dbg !40
%2 = getelementptr inbounds %class.anon, %class.anon* %ref.tmp, i32 0, i32 1, !dbg !40
%3 = load i32, i32* %banana, align 4, !dbg !42
store i32 %3, i32* %2, align 4, !dbg !40
%4 = getelementptr inbounds %class.anon, %class.anon* %ref.tmp, i32 0, i32 2, !dbg !40
%5 = load i32, i32* %cherry, align 4, !dbg !43
store i32 %5, i32* %4, align 4, !dbg !40

!39 = !DILocation(line: 10, column: 9, scope: !4)
!40 = !DILocation(line: 13, column: 9, scope: !4)
!41 = !DILocation(line: 14, column: 35, scope: !4)
!42 = !DILocation(line: 15, column: 36, scope: !4)
!43 = !DILocation(line: 16, column: 36, scope: !4)

Notice that both the GEP and the store are associated with line 13 (as expected), however the loads are associated with lines 14,15,16.
We expect these loads to be associated with line 13.

Notice that if the code was like this:

13.       [apple, banana, cherry]{
14.           printf("apple = %d\n",apple);
15.           printf("banana = %d\n",banana);
16.           printf("cherry = %d\n",cherry);
           }

Then the loads would be associated with line 13.

Diff Detail

Event Timeline

ABataev updated this revision to Diff 32496.Aug 18 2015, 9:05 PM
ABataev retitled this revision from to Improve debug info for implicitly captured vars in lambdas.
ABataev updated this object.
ABataev added reviewers: echristo, rjmccall, rsmith.
ABataev added a subscriber: cfe-commits.
ABataev retitled this revision from Improve debug info for implicitly captured vars in lambdas to [DEBUG INFO] Source correlation for lambda captured values..Aug 18 2015, 9:33 PM
ABataev updated this object.
ABataev updated this object.
vsk added a subscriber: vsk.Aug 22 2015, 9:32 PM
echristo edited edge metadata.Aug 24 2015, 11:00 PM

How about:

  1. [apple,
  2. banana,
  3. cherry]{
  4. printf("apple = %d\n",apple);
  5. printf("banana = %d\n",banana);
  6. printf("cherry = %d\n",cherry);

Should be 13, 14, 15 yes?

-eric

Yes, you're right, and it will be 13, 14, 15. It is implemented already
and this patch does not break this.

Best regards,

Alexey Bataev

Software Engineer
Intel Compiler Team

25.08.2015 9:00, Eric Christopher пишет:

echristo added a comment.

How about:

  1. [apple,
  2. banana,
  3. cherry]{
  4. printf("apple = %d\n",apple);
  5. printf("banana = %d\n",banana);
  6. printf("cherry = %d\n",cherry);

    Should be 13, 14, 15 yes?

    -eric

http://reviews.llvm.org/D12134

Looks like the initial mail didn't hit the mailing list? Does someone want
to restart this review and/or forward that initial mail with the
patch/description/etc?

Hmm, my mistake, it did - my mail client's just not threaded it together
for some reason. :/

ABataev abandoned this revision.Aug 27 2015, 8:18 PM