The message seems to be issued by LLVM, but I’m not sure. Now I don’t have enough time to analyze this problem, as the error is not reproduced on my local WOW64 or 32-bit ARM machines.
Does anyone know anything about the error? Also, is this an issue should be filed?
I thought this was an unusual case so I shared the info. I am not going to try to solve this problem right now.
This happens when using FixedPoint. However, FixedPoints are integer types at the LLVM IR level, so I don’t think it’s a problem with FixedPoint itself.
This may be related to inlining; I tried to make an MWE, but simple or overly complex operations do not raise the error.
I can’t reproduce this problem, but can you try to outline the _w function in ColorBlendModes (by @noinline). It seems that this function doesn’t gets inlined in my Julia (1.6.1 and 1.5.2) but it gets inlined in your test and generates a lots of LLVM IR.
But log of Github action shows different output of LLVM IR, and _w is disappear. The codegen is different, so I can’t reproduce the error on my computer.
%87 = call [3 x [1 x i8]] @j__mapc_459({}* readonly inttoptr (i32 -379120728 to {}*), [1 x [1 x i8]]* nocapture readonly %4, [3 x [1 x i8]]* nocapture readonly %3, [3 x [1 x i8]]* nocapture readonly %5)
I have confirmed that this mapc() by itself does not cause the problem.
I notice that there are a lots of lcnt there which is not showed in my case (after I inline w and some other functions manually to match the your Github action output), it seems that this is used for code coverage (need confirm here), and you have a lots of small nested function call which leads to hundred of lcnt instructions (and maybe that cause LLVM allocates a lot of register). Is this the real cause?
Edit: I turn on code-coverage on my computer, but it still doesn’t throw any error, even if it has hundreds of lcnt. Maybe not the cause but worth noting here.
Yeah, it’s super strange, since inserting these short-living operations shouldn’t break register allocation.
Maybe you should file an issue and move the discussion there. And if you can reproduce this problem, can you following this page Improving LLVM optimizations for Julia and dump all the pass information? So it’s easy to locate the problematic pass.