Can't reproduce on Linux. The input bytecode file generates a 3228 line x86
assembly file.

What format or encoding is the llc -debug log file in?

Log is just plain bzip2 archive without any TAR'ing.

The end look very suspicious:

             Selecting: 0xfb2b08: i32 = TargetConstant <0>
             => 0xfb2b08: i32 = TargetConstant <0>
             Selecting: 0xfb1408: ch = store 0xfb1278, 0xfb11b0, 0xe5bee8,

0xe5c018
Selecting: 0xf9c5d0: i32 = TargetFrameIndex <22>

and all of this ("Selecting" lines) moves to the right until crash

Looking at the --debug output on linux, yields some information:

1. There is a LOT of recursion going on here, about 50,000 calls
2. The recursion goes quite deep .. I'd say over 1,000 calls
3. The problem is occuring in instruction selection.

So, I'm changing the topic of this to "Instruction Selection Deeply Recurses"

I'll also attach the linux "llc --debug" output.

Output from llc --debug on Linux
This is a bzip2 compressed text file of the output from llc --debug when run on
attachment 338 on Linux. The file shows massively deep recursion that should be
avoided.

There is potential loop in Select->SelectCode->Select_*->Select

• = load, for example

The cheap workaround will be constructing objects in Select_ on heap, not on
stack - this will allow deeper recursion

Yep. This is a known problem that is causing me considerable headache. Using a
worklist model to deal with the chain dependencies should help a lot (sort like
a list scheduling). Just don't have the time to deal with it right now.

This is an important class of program that LLVM should handle without failing or
significantly recursing. While it only causes immediate grief on some platforms,
it would be prudent to add the .c file to the llvm-test suite so that we ensure
this problem does not regress.

Anton: what's the license for the .c file that you attached? Is it okay for us
to use this code in the llvm-test suite?

Reid!

There is already a license header in the file:

• Copyright 1993, Dr. James J. Gillogly
• This code may be freely used in any application.
  */

So, I think it's ok to use source in tests. You might also take MD5 source code
from libiberty distribution - the problem does exist there.

Sorry, as you can tell, I didn't even look at the code :)

I just assumed it was raw.

Thanks for cluing me in.

Reid

Fixed.

mentioned in issue llvm/llvm-bugzilla-archive#851