forked from OSchip/llvm-project
941fa7588b
so we can stop using DW_OP_bit_piece with the wrong semantics. The entire back story can be found here: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161114/405934.html The gist is that in LLVM we've been misinterpreting DW_OP_bit_piece's offset field to mean the offset into the source variable rather than the offset into the location at the top the DWARF expression stack. In order to be able to fix this in a subsequent patch, this patch introduces a dedicated DW_OP_LLVM_fragment operation with the semantics that we used to apply to DW_OP_bit_piece, which is what we actually need while inside of LLVM. This patch is complete with a bitcode upgrade for expressions using the old format. It does not yet fix the DWARF backend to use DW_OP_bit_piece correctly. Implementation note: We discussed several options for implementing this, including reserving a dedicated field in DIExpression for the fragment size and offset, but using an custom operator at the end of the expression works just fine and is more efficient because we then only pay for it when we need it. Differential Revision: https://reviews.llvm.org/D27361 rdar://problem/29335809 llvm-svn: 288683 |
||
|---|---|---|
| .. | ||
| address-spaces.ll | ||
| alignment.ll | ||
| basictest.ll | ||
| big-endian.ll | ||
| dbg-single-piece.ll | ||
| fca.ll | ||
| mem-par-metadata-sroa.ll | ||
| phi-and-select.ll | ||
| ppcf128-no-fold.ll | ||
| pr26972.ll | ||
| slice-order-independence.ll | ||
| slice-width.ll | ||
| vector-conversion.ll | ||
| vector-lifetime-intrinsic.ll | ||
| vector-promotion.ll | ||
| vectors-of-pointers.ll | ||