search

Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

"WebAssembly Fix Irreducible Control Flow" pass OOMs on a huge function #47418

Open Quuxplusone opened 3 years ago

Quuxplusone commented 3 years ago
Bugzilla Link PR48449
Status NEW
Importance P normal
Reported by Nick Zavaritsky (mejedi@gmail.com)
Reported on 2020-12-09 00:50:07 -0800
Last modified on 2020-12-13 12:34:28 -0800
Version 11.0
Hardware PC All
CC aheejin@gmail.com, alonzakai@gmail.com, dblaikie@gmail.com, htmldeveloper@gmail.com, llvm-bugs@lists.llvm.org, llvm@sunfishcode.online, sbc@chromium.org
Fixed by commit(s)
Attachments Disasm.bc.gz (908625 bytes, application/x-gzip)
Blocks
Blocked by
See also 
Created attachment 24250
LLVM IR that causes OOM

Clang/lib/AST/Interp/Disasm.cpp takes excessive time and resources to compile
when targeting WebAssembly. Memory usage exceeds 10GiB. It tends to OOM in
smaller machines.

The frontend completes without issues.

When running

clang -c Disasm.bc -mllvm -debug-pass=Executions

the last line printed before OOM is

[2020-12-08 19:16:08.463129734] 0x2d4fc70 Executing Pass 'WebAssembly Fix
Irreducible Control Flow' on Function
'_ZNK5clang6interp8Function4dumpERN4llvm11raw_ostreamE'
Quuxplusone commented 3 years ago

Attached Disasm.bc.gz (908625 bytes, application/x-gzip): LLVM IR that causes OOM

Quuxplusone commented 3 years ago

When there's enough RAM, it takes over 200 seconds to complete the pass.

[2020-12-09 11:56:34.086331000] 0x7ffdd020e550 Executing Pass 'WebAssembly Fix Irreducible Control Flow' on Function '_ZNK5clang6interp8Function4dumpERN4llvm11raw_ostreamE'...

[2020-12-09 11:59:01.839372000] 0x7ffdd020e550 Freeing Pass 'WebAssembly Fix Irreducible Control Flow' on Function '_ZNK5clang6interp8Fu

Quuxplusone commented 3 years ago

I'm not sure what the LLVM usage of the "assignee" field is. I may not have time to look at this any time soon, so if someone else wants to look earlier, feel free to unassign me. Otherwise you can leave me assigned.

Quuxplusone commented 3 years ago

@kripken, I picked you because IIRC you wrote that code, but I should probably have just CC'd you and let you decide if you want to take it on.

Quuxplusone commented 3 years ago

No problem, that's what I figured. I just wanted to clarify that I can find time for this eventually, but it won't be any time soon since I'm swamped, so others should feel free to take it. (If leaving someone as "assignee" in this bug tracker doesn't fit that, feel free to unassign me - I'm just not familiar with the process here in LLVM-land.)

Quuxplusone commented 3 years ago 
I've found a workaround. The overall code layout is as follows:

foreach instr in chunk:
  switch instr.opcode:
    case op1:
      printOp1NameLoop
      ...
    case op2:
      printOp2NameLoop
      ...
    ...

There are 446 opcodes in total. Under each case label there's a nested loop
printing the name of the particular opcode. Each loop is created due to
PrintName lambda function getting inlined.

Compilation time went back to normal after preventing the lambda function from
getting inlined.