search for: dw_op_bit_piece

...somewhat verbose for partial updates of > SROA’ed aggregates as in the following example: > > // struct s { int i, j }; > // void foo(struct s) { s.j = 0; ... } > > define void @foo(i32 %i, i32 %j) { > %token = call llvm.dbg.value(token %undef, %i, !Struct, > !DIExpression(DW_OP_bit_piece(0, 32))) > call llvm.dbg.value(token %token, %j, !Struct, > !DIExpression(DW_OP_bit_piece(32, 32))) > ... > > ; have to repeat %i here: > %tok2 = call llvm.dbg.value(token %undef, %i, !Struct, > !DIExpression(DW_OP_bit_piece(0, 32))) > call llvm.db...

...g to be somewhat verbose for partial updates of SROA’ed aggregates as in the following example: > > // struct s { int i, j }; > // void foo(struct s) { s.j = 0; ... } > > define void @foo(i32 %i, i32 %j) { >   %token = call llvm.dbg.value(token %undef, %i, !Struct, !DIExpression(DW_OP_bit_piece(0, 32))) >            call llvm.dbg.value(token %token, %j, !Struct, !DIExpression(DW_OP_bit_piece(32, 32))) >   ... > >   ; have to repeat %i here: >   %tok2 = call llvm.dbg.value(token %undef, %i, !Struct, !DIExpression(DW_OP_bit_piece(0, 32))) >           call llvm.dbg.value(t...

...gates as in the following example: >> > >> > // struct s { int i, j }; >> > // void foo(struct s) { s.j = 0; ... } >> > >> > define void @foo(i32 %i, i32 %j) { >> > %token = call llvm.dbg.value(token %undef, %i, !Struct, >> !DIExpression(DW_OP_bit_piece(0, 32))) >> > call llvm.dbg.value(token %token, %j, !Struct, >> !DIExpression(DW_OP_bit_piece(32, 32))) >> > ... >> > >> > ; have to repeat %i here: >> > %tok2 = call llvm.dbg.value(token %undef, %i, !Struct, >> !DIExpression...

We are running into trouble with debug information in that we have registers along with sub registers, and they both point to the same dwarf register. Does LLVM support the DW_OP_piece/bit_piece debug information when allocating a sub-register from a super register? If not, is there any plan to add it? If not, would it be difficult to add? Thanks, Micah -------------- next part -------------- An

On Jul 7, 2011, at 12:08 PM, Villmow, Micah wrote: > We are running into trouble with debug information in that we have registers along with sub registers, and they both point to the same dwarf register. Does LLVM support the DW_OP_piece/bit_piece debug information when allocating a sub-register from a super register? If not, is there any plan to add it? If not, would it be difficult to add?

...piece is larger than or outside of variable call void @llvm.dbg.value(metadata i8* %val_arg.fca.0.extract, i64 0, metadata !11, metadata !19), !dbg !18 !11 = !DILocalVariable(tag: DW_TAG_arg_variable, name: "val", arg: 0, scope: !6, file: !4, line: 1, type: !12) !19 = !DIExpression(DW_OP_bit_piece, 0, 64) piece is larger than or outside of variable call void @llvm.dbg.value(metadata i1 (i8*)* %val_arg.fca.1.extract, i64 0, metadata !11, metadata !20), !dbg !18 !11 = !DILocalVariable(tag: DW_TAG_arg_variable, name: "val", arg: 0, scope: !6, file: !4, line: 1, type: !12) !20 = !...

Thanks for your comments. Replies inline. > The DWARF 5 standard says that > "Address range entries in a range list may not overlap.” > > The reasoning behind this is presumably that if a variable is in more than > one > location at a point all the values need to be identical, or the > information is useless Oh huh, for some reason I was under the impression that they

...stack_value, it must be a the address of the value. However, that is >> backwards incompatible and it seems like quite a stretch. >> > > Seems like a stretch in what sense? The backwards incompatibility is > certainly something to consider (though we went through that with > DW_OP_bit_piece too), but this seems like the design I'd go to first so I'd > like to better understand why it's not the path forward if there's some > more detail about that aspect of the design choice here. > > I guess you described this already, but talking it through for > myself...

...e, and if the expression lacks DW_OP_stack_value, it must be a the address of the value. However, that is backwards incompatible and it seems like quite a stretch. Seems like a stretch in what sense? The backwards incompatibility is certainly something to consider (though we went through that with DW_OP_bit_piece too), but this seems like the design I'd go to first so I'd like to better understand why it's not the path forward if there's some more detail about that aspect of the design choice here. I guess you described this already, but talking it through for myself/maybe others will find...

Debug info today handles two cases reasonably well: 1. At -O0, dbg.declare does a good job describing variables that live at some known stack offset 2. With optimizations, variables promoted to SSA can be described with dbg.value This leaves behind a large hole in our optimized debug info: variables that cannot be promoted, typically because they are address-taken. This is