this ir code segfaults llvm in trunk

https://is.gd/PrmYlA

clang-4.0: error: unable to execute command: Segmentation fault (core dumped)
clang-4.0: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 4.0.0 (trunk 291576)
Target: armv7
Thread model: posix
InstalledDir: /opt/compiler-explorer/clang-trunk/bin
clang-4.0: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
clang-4.0: note: diagnostic msg: Error generating preprocessed source(s) - no preprocessable inputs.
Compiler exited with result code 254

I can't reproduce it with r292463 from the 4.0 release branch.
Please don't post files on third party sites, it breaks the mail
archive.

Joerg

On a debug compiler it looks like only x86 supports "coldcc" so you
need to either implement ARM support or stop using that.

Cheers.

Tim.

Oh, and I noticed you're targeting "armv8" in the actual .ll file.
That's actually 32-bit ARM, which *may* be what you intended (RPi3 is
a 64-bit v8 CPU but their provided OS runs in 32-bit mode for example)
but is slightly odd.

What you probably want is a full triple (specifying a sane ABI as
well), in Thumb mode if you really do want 32-bit code. One of these
for example:

  + aarch64-linux-gnu (64-bit mode).
  + thumbv8-linux-gnueabihf (32-bit mode).

Even if you're not actually targeting Linux, those make for a
known-sane starting point for ELF-based code.

Cheers.

Tim.

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&gt;:

“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
* not necessarily the same ABI on every target - and some ABI will be
chosen even if it is just the c calling convention

Thanks for the tip - much appreciated.

Calling conventions are a bit patchy in LLVM. Some are
language-specific and won't be supported for targets unless someone
decides to port their language to that target. Others are
target-specific and will never be supported elsewhere.

It looks like "coldcc" is one of the former, since Clang never uses
it. Actually only two places even look at it: the inliner and the x86
backend. It was added way back in 2005 and I don't think anyone's done
much with it since.

An alternative "cold" function attribute seems to be slightly more
widely used (and ought to be supported everywhere since it can come
from Clang), though it doesn't change the ABI.

Cheers.

Tim.

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.