Kavon Farvardin

Here's a pretty simple program that segfaults when trying to call the reoptimized function: ```c++ // RUN: %atjitc %s -o %t // RUN: %t > %t.out // RUN: %FileCheck %s...

Happens in aebf52bf and the prior commit. Non-debug stack trace: ``` Thread 1 "matmul" received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? ()...

Brian suggests changing the model so that the predictions are of the log of the running of running time of the function instead of just raw running time. This allows...

Tip: 1. the new pass manager does a good job of improving compilation time for modules with lots of functions.

There's a potential for a double free if the unique_ptr to LLVMModule outlives the LLVMContext. Double check that this isn't occuring.

We can use another server to handle JIT requests if we move to ORC JIT instead of MCJIT. This can offload the work from the system to avoid regressions due...

See here: https://llvm.org/docs/OptBisect.html There's a way to bail out if optimization is taking too long.

See the comment in `alt-ret-tuple.pml` from the regression suite for details. I'm not sure what's going on actually. Referenced in commit 9ad955a7ed7faca1fc01b548b07e59c396819773

Large list literals (nucleic)

3

From the nucleic benchmark's TODO, there seems to be an issue with allocating a large list in the heap from a literal. I believe this is a problem regardless of...

Caught this in the benchmarks directory's parallel `cml-merge` when the message size was set very high. ``` ================== WARNING: ThreadSanitizer: data race (pid=3448) Read of size 8 at 0x7f78c4652ea8 by...