[PATCH] D21818: Add artificial debug information to avoid compiler crash

Robinson, Paul via llvm-commits llvm-commits at lists.llvm.org
Thu Aug 25 10:49:38 PDT 2016


(re-adding llvm-commits which got lost from my previous)

> -----Original Message-----
> From: aprantl at apple.com [mailto:aprantl at apple.com]
> Sent: Thursday, August 25, 2016 10:42 AM
> To: Robinson, Paul
> Cc: Gao, Yunzhong; David Blaikie;
> reviews+D21818+public+b40f0be86340e0e5 at reviews.llvm.org
> Subject: Re: [PATCH] D21818: Add artificial debug information to avoid
> compiler crash
> 
> 
> > On Aug 25, 2016, at 10:37 AM, Robinson, Paul <paul.robinson at sony.com>
> wrote:
> >> -----Original Message-----
> >> From: llvm-commits [mailto:llvm-commits-bounces at lists.llvm.org] On
> Behalf
> >> Of Gao, Yunzhong via llvm-commits
> >> Hi Adrian,
> >> I would not say that attaching an artificial debug location should be
> >> ruled out as
> >> an option, and the original commit r274263 used that approach. But I
> think
> >> David
> >> was suggesting that the verifier could be modified to consider this IR
> as
> >> valid
> >> without the extra debug info (that was my interpretation of what David
> >> said,
> >> but I could be wrong) and therefore I did some investigation here,
> >
> > Right, the line-0 tactic increases debug-info size but the original
> > complaint was because of a verifier failure.  If we can mark the
> > offending artificial calls so that the verifier will allow them,
> > then we don't pay the debug-info size cost in the object file.
> >
> > I'd be happier with a tactic that would automatically deal with this
> > for all cases of artificial calls to hard-coded function names, but
> > it's not immediately clear how to make that work.
> 
> I added the verifier check because having an inlineable function call
> without a debug location to a function with debug info inside a function
> with debug info causes an assertion failure when the backend attempts to
> construct the inline scopes.
> Do we know that it is safe to relax the verifier here?
> 
> -- adrian
> 
> 
Well, maybe not, and that would be a good experiment for Gao to try--
undo the original patch, so it doesn't mark the call with line-0, and
make the called function inlineable, and see if it dies when generating
the inlined scopes.
--paulr



More information about the llvm-commits mailing list