Clamping of llvm llc to -O1 and -O2

We currently clamp the optimization level of llvm llc (3.9 and 4.0) within [1,2].

The reason is that with -O0, the naive register allocator can topple over with

    Error while trying to spill R1 from class GPR: Cannot scavenge register
    without an emergency spill slot!

and with -O3 the llvm::SelectionDAGISel::LowerArguments may break, when compiling rts/HeapStackCheck.cmm with the stage1 ghc.

0  llc                      0x0000000102ae63e8 llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 40
1  llc                      0x0000000102ae69a6 SignalHandler(int) + 358
2  libsystem_platform.dylib 0x00007fffc23f4b3a _sigtramp + 26
3  libsystem_c.dylib        0x00007fffc226498b __vfprintf + 17876
4  llc                      0x00000001029d5123 llvm::SelectionDAGISel::LowerArguments(llvm::Function const&) + 5699
5  llc                      0x0000000102a21a35 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 3381
6  llc                      0x0000000102a202b1 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1457
7  llc                      0x0000000101bdc474 (anonymous namespace)::ARMDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 20
8  llc                      0x00000001025573a6 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 134
9  llc                      0x000000010274fb12 llvm::FPPassManager::runOnFunction(llvm::Function&) + 498
10 llc                      0x000000010274fd23 llvm::FPPassManager::runOnModule(llvm::Module&) + 67
11 llc                      0x00000001027501b8 llvm::legacy::PassManagerImpl::run(llvm::Module&) + 920
12 llc                      0x000000010195f075 compileModule(char**, llvm::LLVMContext&) + 12133
13 llc                      0x000000010195bf0b main + 491
14 libdyld.dylib            0x00007fffc21e5235 start + 1
Stack dump:
0.  Program arguments: llc -O3 -mtriple=arm-unknown-linux-gnueabihf -enable-tbaa /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_6.bc -o /var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_7.lm_s
1.  Running pass 'Function Pass Manager' on module '/var/folders/fv/xqjrpfj516n5xq_m_ljpsjx00000gn/T/ghc33674_0/ghc_6.bc'.
2.  Running pass 'ARM Instruction Selection' on function '@"stg_gc_f1$def"'

opt and llc should respect -opt_lo and -opt_lc, such that -opt_lc=-O3 can be used to validate the behaviour.

Trac metadata

Trac field	Value
Version	8.3
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler (LLVM)
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	bgamari
Operating system
Architecture

changed milestone to %8.4.1

changed weight to 5

added LLVM backend Tbug Trac import labels

Note that you can pass -debug-pass=Structure and -debug-pass=Arguments as arguments to opt and `llc.

as in

llc -O1 -debug-pass=Structure < /dev/null >/dev/nulll

or with a triple:

llc -mtriple=arm-unknown-linux-gnueabihf -O1 -debug-pass=Structure < /dev/null >/dev/nulll

changed milestone to %8.6.1

This ticket won't be resolved in 8.4; remilestoning for 8.6. Do holler if you are affected by this or would otherwise like to work on it.

I believe this can be addressed in a way similar to the approach in D4421.

changed milestone to %8.8.1

These won't be fixed for in GHC 8.6.

changed milestone to %8.10.1

Bumping milestones of low-priority tickets.

added Pnormal label

I've tried to build a cross-compiler targeting arm-linux-gnueabihf from the master branch which uses the latest LLVM 9.0.0, and the -O3 flag seems to no longer cause this LLVM failure. I have a fully working stage1 GHC and the libraries.

The -O0, however, still doesn't work.

I'm thinking that maybe we should remove the upper limit of the optimization flag passed to llc and opt since this is no longer a problem.

Do you think it's worth submitting a patch?

removed milestone