[llvm-dev] this ir code segfaults llvm in trunk

[Mehdi Amini via llvm-dev]

> On Feb 6, 2017, at 11:50 AM, Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On Mon, Feb 6, 2017 at 12:36 PM, Tim Northover <t.p.northover at gmail.com <mailto:t.p.northover at gmail.com>> wrote:
> On 5 February 2017 at 23:41, Andrew Kelley via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> > Target: armv7
> 
> On a debug compiler it looks like only x86 supports "coldcc" so you
> need to either implement ARM support or stop using that.
> 
> Thanks Tim and apologies for my sloppy bug report.
> 
> Here is the text from the language reference <http://llvm.org/docs/LangRef.html#calling-conventions>:
> 
> “coldcc” - The cold calling convention
> This calling convention attempts to make code in the caller as efficient as possible under the assumption that the call is not commonly executed. As such, these calls often preserve all registers so that the call does not break any live ranges in the caller side. This calling convention does not support varargs and requires the prototype of all callees to exactly match the prototype of the function definition. Furthermore the inliner doesn’t consider such function calls for inlining.
> 
> The phrasing of "attempts", "often", and the fact that it provides hints to the inliner makes it sound like coldcc is:
> 
>  * useful for optimization purposes regardless of an ABI

I’d rather decouple the calling convention from the IR optimization. We already have a function attribute to mark function cold (and that’s what is used by __attribute__((cold)) AFAIK). A single source of truth is preferable here.
So I’d change LangRef to make it clear, and maybe update the pass that deduce function attribute to mark the attribute `cold` when coldcc is present.

— 
Mehdi


>  * not necessarily the same ABI on every target - and some ABI will be chosen even if it is just the c calling convention
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170206/4240537a/attachment.html>