[llvm] r269969 - When looking for a spill slot in reg scavenger, find one that matches RC

[Hal Finkel via llvm-commits]

----- Original Message -----

> From: "Quentin Colombet via llvm-commits"
> <llvm-commits at lists.llvm.org>
> To: "Krzysztof Parzyszek" <kparzysz at codeaurora.org>
> Cc: "Benjamin Kramer" <benny.kra at gmail.com>, "Chandler Carruth via
> llvm-commits" <llvm-commits at lists.llvm.org>
> Sent: Friday, May 20, 2016 1:21:42 PM
> Subject: Re: [llvm] r269969 - When looking for a spill slot in reg
> scavenger, find one that matches RC

> > On May 20, 2016, at 9:11 AM, Krzysztof Parzyszek via llvm-commits <
> > llvm-commits at lists.llvm.org > wrote:
> 

> > Getting to this particular place in register scavenger is an
> > indication of a problem. That should not happen under any
> > conditions, so it qualifies for llvm_unreachable. There is nothing
> > that the user can do to remedy this situation once it happens. That
> > ties to your comment about when to use unreachable vs
> > report_fatal_error.
> 

> > I was under impression that llvm_unreachable expands to nothing in
> > release mode---turns out it is not true. I'd rather remove the
> > report_fatal_error and keep the unreachable in this case.
> 

> My bad, llvm_unreachable does generate a call to abort. I could have
> swear I saw unreachable just being dropped.

It depends on what kind of build you have: 

#ifndef NDEBUG 
#define llvm_unreachable(msg) \ 
::llvm::llvm_unreachable_internal(msg, __FILE__, __LINE__) 
#elif defined(LLVM_BUILTIN_UNREACHABLE) 
#define llvm_unreachable(msg) LLVM_BUILTIN_UNREACHABLE 
#else 
#define llvm_unreachable(msg) ::llvm::llvm_unreachable_internal() 
#endif 

where: 

/// This function calls abort(), and prints the optional message to stderr. 
/// Use the llvm_unreachable macro (that adds location info), instead of 
/// calling this function directly. 
LLVM_ATTRIBUTE_NORETURN void 
llvm_unreachable_internal(const char *msg=nullptr, const char *file=nullptr, 
unsigned line=0); 

-Hal 

> > -Krzysztof
> 

> > On 5/20/2016 11:01 AM, Benjamin Kramer wrote:
> 

> > > report_fatal_error produces user-visible errors, I don't think
> > 
> 
> > > including stack traces there is in any way helpful and will only
> > > cause
> > 
> 
> > > confusion. If a compiler dev doesn't like using a debugger they
> > > can
> > 
> 
> > > still grep for the error message and quickly find where it's
> > > coming
> > 
> 
> > > from ...
> > 
> 

> > > On Fri, May 20, 2016 at 5:51 PM, Krzysztof Parzyszek
> > 
> 
> > > < kparzysz at codeaurora.org > wrote:
> > 
> 

> > > > On 5/20/2016 10:43 AM, Benjamin Kramer wrote:
> > > 
> > 
> 

> > > > > You can
> > > > 
> > > 
> > 
> 
> > > > > easily get a stack trace from a debugger, no need to use
> > > > 
> > > 
> > 
> 
> > > > > llvm_unreachable for that.
> > > > 
> > > 
> > 
> 

> > > > That forces people to use debuggers, which I really don't like.
> > > 
> > 
> 

> > > > Maybe printing the stack trace from report_fatal_error (when
> > > > assertions are
> > > 
> > 
> 
> > > > enabled) would be an option?
> > > 
> > 
> 

> > > > -Krzysztof
> > > 
> > 
> 

> > > > --
> > > 
> > 
> 
> > > > Qualcomm Innovation Center, Inc. is a member of Code Aurora
> > > > Forum,
> > > > hosted by
> > > 
> > 
> 
> > > > The Linux Foundation
> > > 
> > 
> 

> > --
> 
> > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> > hosted by The Linux Foundation
> 
> > _______________________________________________
> 
> > llvm-commits mailing list
> 
> > llvm-commits at lists.llvm.org
> 
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160520/704ffc19/attachment.html>