search for: pr25630

...t thing to do, and it shouldn't be the default behavior. # Correctness The IRBuilder shouldn't assume that the debug loc at its insertion point applies to any instructions it emits. It doesn't have enough information to make that connection. This assumption leads to bugs like llvm.org/PR25630 <http://llvm.org/PR25630>. I.e it creates situations in which we silently push around incorrect DILocations without realizing it, because the debug locs in the IR look nice and contiguous. To fix the issue, clients of IRBuilder should be required to either: 1. Explicitly set the correct deb...

...be the default behavior. >> >> # Correctness >> >> The IRBuilder shouldn't assume that the debug loc at its insertion point applies to any instructions it emits. It doesn't have enough information to make that connection. This assumption leads to bugs like llvm.org/PR25630. I.e it creates situations in which we silently push around incorrect DILocations without realizing it, because the debug locs in the IR look nice and contiguous. > > I agree with your analysis. > >> >> To fix the issue, clients of IRBuilder should be required to either: &gt...

...Debugify: Missing line 3 >> CheckDebugify: Missing line 4 >> ... >> CheckDebugify: Missing line 33 > > This could be a handy way to create new targeted test cases at the IR/MIR level. Something like this would have helped triage issues like llvm.org/ <http://llvm.org/>PR25630 as well. > > 2) Assert that combines preserve debug info. > > If there's an important API like "CombineTo(From, To)", it could be useful to assert that the To node has at least as much debug info as the From node. I'm experimenting with this in SelectionDAG (llvm.org...

> On Nov 13, 2017, at 11:53 AM, Vedant Kumar via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Amara, > >> On Nov 10, 2017, at 9:12 AM, Amara Emerson via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Hi everyone, >> >> This RFC concerns the design and architecture of a generic machine

...;>> >>>> # Correctness >>>> >>>> The IRBuilder shouldn't assume that the debug loc at its insertion point applies to any instructions it emits. It doesn't have enough information to make that connection. This assumption leads to bugs like llvm.org/PR25630. I.e it creates situations in which we silently push around incorrect DILocations without realizing it, because the debug locs in the IR look nice and contiguous. >>> >>> I agree with your analysis. >>> >>>> >>>> To fix the issue, clients of IRB...