[SelectionDAG] Pick correct frame index in LowerArguments
Summary:
SelectionDAGISel::LowerArguments is associating arguments
with frame indices (FuncInfo->setArgumentFrameIndex). That
information is later on used by EmitFuncArgumentDbgValue to
create DBG_VALUE instructions that denotes that a variable
can be found on the stack.
I discovered that for our (big endian) out-of-tree target
the association created by SelectionDAGISel::LowerArguments
sometimes is wrong. I've seen this happen when a 64-bit value
is passed on the stack. The argument will occupy two stack
slots (frame index X, and frame index X+1). The fault is
that a call to setArgumentFrameIndex is associating the
64-bit argument with frame index X+1. The effect is that the
debug information (DBG_VALUE) will point at the least significant
part of the arguement on the stack. When printing the
argument in a debugger I will get the wrong value.
I managed to create a test case for PowerPC that seems to
show the same kind of problem.
The bugfix will look at the datalayout, taking endianness into
account when examining a BUILD_PAIR node, assuming that the
least significant part is in the first operand of the BUILD_PAIR.
For big endian targets we should use the frame index from
the second operand, as the most significant part will be stored
at the lower address (using the highest frame index).
Reviewers: bogner, rnk, hfinkel, sdardis, aprantl
Reviewed By: aprantl
Subscribers: nemanjai, aprantl, llvm-commits, igorb
Differential Revision: https://reviews.llvm.org/D37740
llvm-svn: 313901
2017-09-22 02:52:08 +08:00
; RUN: llc < %s -O1 -stop-after=livedebugvalues -o - | FileCheck %s
; This ll-file was created by:
; clang --target=powerpc-apple-darwin9 -O1 -S -g -emit-llvm debuginfo-stackarg.c
;
; with debuginfo-stackarg.c being the program:
; long long foo(long long bar1, long long bar2, long long bar3, long long bar4, long long bar5)
; {
; return bar1 + bar2 + bar3 + bar4 + bar5;
; }
; ModuleID = 'debuginfo-stackarg.c'
source_filename = "debuginfo-stackarg.c"
target datalayout = "E-m:o-p:32:32-f64:32:64-n32"
target triple = "powerpc-apple-macosx10.5.0"
; Function Attrs: nounwind readnone ssp uwtable
define i64 @foo ( i64 %bar1 , i64 %bar2 , i64 %bar3 , i64 %bar4 , i64 %bar5 ) local_unnamed_addr #0 !dbg !8 {
; Variable bar5 should be associated with a position on the stack (offset relative r1).
; Let's verify that we point out the start address (lowest address).
;
; First find the metadata id for bar5.
; CHECK: !17 = !DILocalVariable(name: "bar5", arg: 5
;
; Now check that we got two entries on the fixed stack with "expected" offsets.
; CHECK-LABEL: fixedStack:
; CHECK: id: 0, type: default, offset: 60, size: 4
; CHECK: id: 1, type: default, offset: 56, size: 4
; CHECK-NOT: id: 2
; CHECK-LABEL: stack:
;
; Finally check the resulting function body.
; We expect to find a DBG_VALUE refering to the metadata id for bar5, using the lowest
; of the two fixed stack offsets found earlier.
; CHECK-LABEL: body:
2018-02-01 06:04:26 +08:00
; CHECK: DBG_VALUE $r1, 0, !17, !DIExpression(DW_OP_plus_uconst, 56)
[SelectionDAG] Pick correct frame index in LowerArguments
Summary:
SelectionDAGISel::LowerArguments is associating arguments
with frame indices (FuncInfo->setArgumentFrameIndex). That
information is later on used by EmitFuncArgumentDbgValue to
create DBG_VALUE instructions that denotes that a variable
can be found on the stack.
I discovered that for our (big endian) out-of-tree target
the association created by SelectionDAGISel::LowerArguments
sometimes is wrong. I've seen this happen when a 64-bit value
is passed on the stack. The argument will occupy two stack
slots (frame index X, and frame index X+1). The fault is
that a call to setArgumentFrameIndex is associating the
64-bit argument with frame index X+1. The effect is that the
debug information (DBG_VALUE) will point at the least significant
part of the arguement on the stack. When printing the
argument in a debugger I will get the wrong value.
I managed to create a test case for PowerPC that seems to
show the same kind of problem.
The bugfix will look at the datalayout, taking endianness into
account when examining a BUILD_PAIR node, assuming that the
least significant part is in the first operand of the BUILD_PAIR.
For big endian targets we should use the frame index from
the second operand, as the most significant part will be stored
at the lower address (using the highest frame index).
Reviewers: bogner, rnk, hfinkel, sdardis, aprantl
Reviewed By: aprantl
Subscribers: nemanjai, aprantl, llvm-commits, igorb
Differential Revision: https://reviews.llvm.org/D37740
llvm-svn: 313901
2017-09-22 02:52:08 +08:00
entry:
tail call void @llvm.dbg.value ( metadata i64 %bar1 , metadata !13 , metadata !DIExpression ( ) ) , !dbg !18
tail call void @llvm.dbg.value ( metadata i64 %bar2 , metadata !14 , metadata !DIExpression ( ) ) , !dbg !19
tail call void @llvm.dbg.value ( metadata i64 %bar3 , metadata !15 , metadata !DIExpression ( ) ) , !dbg !20
tail call void @llvm.dbg.value ( metadata i64 %bar4 , metadata !16 , metadata !DIExpression ( ) ) , !dbg !21
tail call void @llvm.dbg.value ( metadata i64 %bar5 , metadata !17 , metadata !DIExpression ( ) ) , !dbg !22
%add = add nsw i64 %bar2 , %bar1 , !dbg !23
%add1 = add nsw i64 %add , %bar3 , !dbg !24
%add2 = add nsw i64 %add1 , %bar4 , !dbg !25
%add3 = add nsw i64 %add2 , %bar5 , !dbg !26
ret i64 %add3 , !dbg !27
}
; Function Attrs: nounwind readnone speculatable
declare void @llvm.dbg.value ( metadata , metadata , metadata ) #1
attributes #0 = { nounwind readnone ssp uwtable }
attributes #1 = { nounwind readnone s p e c u l a t a b l e }
!llvm.dbg.cu = ! { !0 }
!llvm.module.flags = ! { !3 , !4 , !5 , !6 }
!llvm.ident = ! { !7 }
!0 = distinct !DICompileUnit ( language: D W _ L A N G _ C 99 , file: !1 , producer: "clang version 6.0.0" , isOptimized: true , runtimeVersion: 0 , emissionKind: F u l l D e b u g , enums: !2 )
!1 = !DIFile ( filename: "debuginfo-stackarg.c" , directory: "/repo" )
!2 = ! { }
!3 = ! { i32 2 , !"Dwarf Version" , i32 2 }
!4 = ! { i32 2 , !"Debug Info Version" , i32 3 }
!5 = ! { i32 1 , !"wchar_size" , i32 4 }
!6 = ! { i32 7 , !"PIC Level" , i32 2 }
!7 = ! { !"clang version 6.0.0" }
!8 = distinct !DISubprogram ( name: "foo" , scope: !1 , file: !1 , line: 1 , type: !9 , isLocal: false , isDefinition: true , scopeLine: 2 , flags: D I F l a g P r o t o t y p e d , isOptimized: true , unit: !0 , variables: !12 )
!9 = !DISubroutineType ( types: !10 )
!10 = ! { !11 , !11 , !11 , !11 , !11 , !11 }
!11 = !DIBasicType ( name: "long long int" , size: 64 , encoding: D W _ A T E _ s i g n e d )
!12 = ! { !13 , !14 , !15 , !16 , !17 }
!13 = !DILocalVariable ( name: "bar1" , arg: 1 , scope: !8 , file: !1 , line: 1 , type: !11 )
!14 = !DILocalVariable ( name: "bar2" , arg: 2 , scope: !8 , file: !1 , line: 1 , type: !11 )
!15 = !DILocalVariable ( name: "bar3" , arg: 3 , scope: !8 , file: !1 , line: 1 , type: !11 )
!16 = !DILocalVariable ( name: "bar4" , arg: 4 , scope: !8 , file: !1 , line: 1 , type: !11 )
!17 = !DILocalVariable ( name: "bar5" , arg: 5 , scope: !8 , file: !1 , line: 1 , type: !11 )
!18 = !DILocation ( line: 1 , column: 25 , scope: !8 )
!19 = !DILocation ( line: 1 , column: 41 , scope: !8 )
!20 = !DILocation ( line: 1 , column: 57 , scope: !8 )
!21 = !DILocation ( line: 1 , column: 73 , scope: !8 )
!22 = !DILocation ( line: 1 , column: 89 , scope: !8 )
!23 = !DILocation ( line: 3 , column: 15 , scope: !8 )
!24 = !DILocation ( line: 3 , column: 22 , scope: !8 )
!25 = !DILocation ( line: 3 , column: 29 , scope: !8 )
!26 = !DILocation ( line: 3 , column: 36 , scope: !8 )
!27 = !DILocation ( line: 3 , column: 3 , scope: !8 )