[llvm] r334118 - [Debugify] Move debug value intrinsics closer to their operand defs

Vedant Kumar via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 8 11:16:38 PDT 2018



> On Jun 8, 2018, at 9:41 AM, Davide Italiano <davide at freebsd.org> wrote:
> 
> On Wed, Jun 6, 2018 at 12:05 PM, Vedant Kumar via llvm-commits
> <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
>> Author: vedantk
>> Date: Wed Jun  6 12:05:42 2018
>> New Revision: 334118
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=334118&view=rev
>> Log:
>> [Debugify] Move debug value intrinsics closer to their operand defs
>> 
>> Before this patch, debugify would insert debug value intrinsics before the
>> terminating instruction in a block. This had the advantage of being simple,
>> but was a bit too simple/unrealistic.
>> 
>> This patch teaches debugify to insert debug values immediately after their
>> operand defs. This enables better testing of the compiler.
>> 
>> For example, with this patch, `opt -debugify-each` is able to identify a
>> vectorizer DI-invariance bug fixed in llvm.org/PR32761. In this bug, the
>> vectorizer produced different output with/without debug info present.
>> 
>> Reverting Davide's bugfix locally, I see:
>> 
> 
> Another idea that came to my mind and I wanted to discuss
> with you in person yesterday (although we didn't get a chance) is that
> we could randomize the insertion of the debug value intrinsic (using
> `OrderedBasicBlock`or the dominator directly to make sure the
> dominance relation is enforced).
> I'm not entirely sure if it's going to find new bugs, but maybe it's
> worth a shot.

That's an interesting idea. I think it certainly could be worth a shot. Having more debug values in a Module should exercise at least a few more paths in the compiler.

Would you like a take a stab at this? I'm not sure what the cleanest approach with be (and I'm not familiar with OrderedBasicBlock).

vedant

> 
> --
> Davide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180608/0718a50a/attachment.html>


More information about the llvm-commits mailing list