Ponyc: Compiler crash in ponyc 0.28.0 with LLVM 7+ for certain projects

[EpicEric]

Originally reported while working on #3138.

A few Pony projects I tested crash ponyc 0.28.0 on the Writing ./foo.o step when running in Docker. For example, pony-kafka or one of my personal projects. Some projects (for example, pony-stable) compile just fine.

For example, with pony-kafka I get the following logs and the error code 139:

$ docker run -v /tmp/pony-kafka:/src/main ponylang/ponyc:0.28.0 ponyc examples/simple  
Building builtin -> /usr/local/lib/pony/0.28.0/packages/builtin
Building examples/simple -> /src/main/examples/simple
Building net -> /usr/local/lib/pony/0.28.0/packages/net
Building collections -> /usr/local/lib/pony/0.28.0/packages/collections
Building ponytest -> /usr/local/lib/pony/0.28.0/packages/ponytest
Building time -> /usr/local/lib/pony/0.28.0/packages/time
Building random -> /usr/local/lib/pony/0.28.0/packages/random
Building ../../pony-kafka/customlogger -> /src/main/pony-kafka/customlogger
Building ../../pony-kafka -> /src/main/pony-kafka
Building custombuffered -> /src/main/pony-kafka/custombuffered
Building codecs -> /src/main/pony-kafka/custombuffered/codecs
Building ../../utils/bool_converter -> /src/main/pony-kafka/utils/bool_converter
Building itertools -> /usr/local/lib/pony/0.28.0/packages/itertools
Building customnet -> /src/main/pony-kafka/customnet
Building fsm -> /src/main/pony-kafka/fsm
Building options -> /usr/local/lib/pony/0.28.0/packages/options
Building compression -> /src/main/pony-kafka/compression
Generating
 Reachability
 Selector painting
 Data prototypes
 Data types
 Function prototypes
 Functions
 Descriptors
Optimising
Writing ./simple.o
Stack dump:
0.  Running pass 'Function Pass Manager' on module 'simple'.
1.  Running pass 'Greedy Register Allocator' on function '@3359'

This doesn't happen for the 0.27.0 Docker tag, when using the distribution release of Pony outside of the container, or when using ponyc --debug. For these cases, it will compile (or just fail normally with error code 255 when trying to link the required libraries).

I have yet to test the distribution release of Pony _inside_ the container.

[EpicEric]

Removing the make parameters here does not solve the issue.

[mfelsche]

ponyc in the Dockerfile is built using the release llvm from releases.llvm.org.
We should switch to using vendored llvm there too.

[mfelsche]

This might be related to #3126 ?

[EpicEric]

Probably not. They crash on different compilation steps (Writing ./foo.o instead of Optimising), and on different conditions (i.e. both LLVM 7.0.1 in the Ubuntu image and LLVM 5 in #3138 trigger this issue; the other issue only happens on LLVM 3.9.1).

[SeanTAllen]

This is probably a LLVM 7.0.1 bug?

[jemc]

To get the rest of the stack dump info about this, we'd need to reproduce with LLVM compiled in debug mode instead of release mode.

[SeanTAllen]

@EpicEric Is your project avaiable so I could try this with vendored LLVM 7.0.1 to see if I have the problem?

[EpicEric]

Here's my repository: https://github.com/EpicEric/pcs3866-languages-and-compilers

Using ponyc for either building or running on Docker will cause the crash if it doesn't have the --debug flag.

[EpicEric]

This issue happens on the new Alpine image ponylang/ponyc:alpine as well, under the same conditions (i.e. in either docker buildor docker run, but not when ponyc has the --debug flag). But the stack dump isn't printed:

$ docker build -t epiceric/basicc .                                                  
Sending build context to Docker daemon  236.5kB
Step 1/4 : FROM ponylang/ponyc:alpine
 ---> 6f50ce3a71c4
Step 2/4 : COPY basicc basicc
 ---> Using cache
 ---> aa409300d747
Step 3/4 : RUN ponyc -o /bin basicc
 ---> Running in af3b55f3a92a
Building builtin -> /usr/local/lib/pony/0.28.0/packages/builtin
Building basicc -> /src/main/basicc
Building collections -> /usr/local/lib/pony/0.28.0/packages/collections
Building ponytest -> /usr/local/lib/pony/0.28.0/packages/ponytest
Building time -> /usr/local/lib/pony/0.28.0/packages/time
Building random -> /usr/local/lib/pony/0.28.0/packages/random
Building cli -> /usr/local/lib/pony/0.28.0/packages/cli
Building collections/persistent -> /usr/local/lib/pony/0.28.0/packages/collections/persistent
Building buffered -> /usr/local/lib/pony/0.28.0/packages/buffered
Building files -> /usr/local/lib/pony/0.28.0/packages/files
Building term -> /usr/local/lib/pony/0.28.0/packages/term
Building promises -> /usr/local/lib/pony/0.28.0/packages/promises
Building strings -> /usr/local/lib/pony/0.28.0/packages/strings
Building signals -> /usr/local/lib/pony/0.28.0/packages/signals
Building capsicum -> /usr/local/lib/pony/0.28.0/packages/capsicum
Building format -> /usr/local/lib/pony/0.28.0/packages/format
Generating
 Reachability
 Selector painting
 Data prototypes
 Data types
 Function prototypes
 Functions
 Descriptors
Optimising
Writing /bin/basicc.o
The command '/bin/sh -c ponyc -o /bin basicc' returned a non-zero code: 139

[EpicEric]

This is what git bisect gave me:

68a4984a91d653c4e53316b419143715a206cf15 is the first bad commit
commit 68a4984a91d653c4e53316b419143715a206cf15
Author: Sean T Allen <[email protected]>
Date:   Sat Mar 9 07:40:46 2019 -0500

    Upgrade Docker image to use LLVM 7.0.1 (#3079)

    Part of our general move off of LLVM 3.9.1.

:100644 100644 fd8051e3685fb56cfc8e57785ebf127a7b526fc7 587872f7cb7fb4524c55c306c5da74dd54df807f M  Dockerfile

Which makes sense, since the Dockerfile was updated in this commit.

Here is my git bisect log:

git bisect start
# good: [506acdf720feb92bf20ff1599795641edbfdbbbc] Prep for 0.27.0 release
git bisect good 506acdf720feb92bf20ff1599795641edbfdbbbc
# bad: [4f0fc19f956ef54a4cd146863c7211a6c1d298db] Prep for 0.28.0 release
git bisect bad 4f0fc19f956ef54a4cd146863c7211a6c1d298db
# good: [89b046b93b59fdb5c57b6ce4db04d0e496f62c18] Fix centos-7-3.9.1 release building
git bisect good 89b046b93b59fdb5c57b6ce4db04d0e496f62c18
# bad: [6a85945f2ffab0b1809259f276295831f6591c22] Update CHANGELOG for PR #3086 [skip ci]
git bisect bad 6a85945f2ffab0b1809259f276295831f6591c22
# bad: [c140ebf9a983ba089e5e1a2434446a7e3ac0e9bc] Update CHANGELOG for PR #3079 [skip ci]
git bisect bad c140ebf9a983ba089e5e1a2434446a7e3ac0e9bc
# good: [34c2a28c041e3001801fdabb0812dee056675024] Add missing CHANGELOG note for Jessie deprecation
git bisect good 34c2a28c041e3001801fdabb0812dee056675024
# good: [08bd39eecca8540280a623d98d11b2e0be991d25] Run macOS CI on Cirrus (#3080)
git bisect good 08bd39eecca8540280a623d98d11b2e0be991d25
# bad: [68a4984a91d653c4e53316b419143715a206cf15] Upgrade Docker image to use LLVM 7.0.1 (#3079)
git bisect bad 68a4984a91d653c4e53316b419143715a206cf15
# first bad commit: [68a4984a91d653c4e53316b419143715a206cf15] Upgrade Docker image to use LLVM 7.0.1 (#3079)

[SeanTAllen]

I get this crash using the vendored LLVM 7.0.1 so this isn't the ABI issue that 7.1.0 addresses. This is definitely a "real bug".

[SeanTAllen]

Release version stack trace from MacOS where it also happens:

(lldb) bt
* thread #1: tid = 0x16e274, 0x0000000100d21e01 ponyc`llvm::SplitEditor::transferValues() + 603, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x0000000100d21e01 ponyc`llvm::SplitEditor::transferValues() + 603
    frame #1: 0x0000000100d2348a ponyc`llvm::SplitEditor::finish(llvm::SmallVectorImpl<unsigned int>*) + 240
    frame #2: 0x0000000100ce26a4 ponyc`(anonymous namespace)::RAGreedy::selectOrSplitImpl(llvm::LiveInterval&, llvm::SmallVectorImpl<unsigned int>&, llvm::SmallSet<unsigned int, 16u, std::__1::less<unsigned int> >&, unsigned int) + 5576
    frame #3: 0x0000000100cdf72c ponyc`(anonymous namespace)::RAGreedy::selectOrSplit(llvm::LiveInterval&, llvm::SmallVectorImpl<unsigned int>&) + 130
    frame #4: 0x0000000100cda381 ponyc`llvm::RegAllocBase::allocatePhysRegs() + 125
    frame #5: 0x0000000100cdf287 ponyc`(anonymous namespace)::RAGreedy::runOnMachineFunction(llvm::MachineFunction&) + 1825
    frame #6: 0x0000000100c5ffbc ponyc`llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 114
    frame #7: 0x00000001013a2e6a ponyc`llvm::FPPassManager::runOnFunction(llvm::Function&) + 358
    frame #8: 0x00000001013a2ff7 ponyc`llvm::FPPassManager::runOnModule(llvm::Module&) + 49
    frame #9: 0x00000001013a32e6 ponyc`llvm::legacy::PassManagerImpl::run(llvm::Module&) + 572
    frame #10: 0x0000000100d6133f ponyc`LLVMTargetMachineEmit(LLVMOpaqueTargetMachine*, LLVMOpaqueModule*, llvm::raw_pwrite_stream&, LLVMCodeGenFileType, char**) + 367
    frame #11: 0x0000000100d61193 ponyc`LLVMTargetMachineEmitToFile + 183
    frame #12: 0x0000000100051ccf ponyc`genobj + 463
    frame #13: 0x0000000100049165 ponyc`genexe + 597
    frame #14: 0x000000010003e29b ponyc`codegen + 219
    frame #15: 0x0000000100082a90 ponyc`generate_passes + 16
    frame #16: 0x0000000100002ad3 ponyc`main + 611
    frame #17: 0x00007fff9100f5ad libdyld.dylib`start + 1
    frame #18: 0x00007fff9100f5ad libdyld.dylib`start + 1

[SeanTAllen]

A bit more info is available if we don't strip debug info:

Writing ./basicc.o
Stack dump:
0.  Running pass 'Function Pass Manager' on module 'basicc'.
1.  Running pass 'Greedy Register Allocator' on function '@collections_HashMap_String_val_t3_U32_val_u4_SyntaxExpressionNumber_ref_SyntaxExpressionVariable_ref_SyntaxExpressionUnary_ref_SyntaxExpressionBinary_ref_u4_SyntaxExpressionNumber_ref_SyntaxExpressionVariable_ref_SyntaxExpressionUnary_ref_SyntaxExpressionBinary_ref_collections_HashEq_String_val_val_ref_update_o3Iooo'

[SeanTAllen]

I don't have any previous experience diagnosing LLVM optimization bugs. I do know that line 1400 in genopt.cc: pmb.populateLTOPassManager(lpm); if turned off, we don't have the crash so, definitely related to the LTO pass in some fashion which matches up with the observed crash.

Interestingly, the only thing I can see being added to lpm is from:

  lpm.add(createTargetTransformInfoWrapperPass(
    machine->getTargetIRAnalysis()));

but turning that off doesn't prevent the crash. If anyone can elucidate more on what is going on here, I'd appreciate it.

[SeanTAllen]

Turning on the "VerifyOutput" option gives us an interesting result for this case:

Instruction does not dominate all uses!
  %180 = tail call i8* @pony_alloc_small(i8* %0, i32 0), !dbg !10382
  %178 = getelementptr inbounds i8, i8* %180, i64 8, !dbg !10382
LLVM fatal error: Broken function found, compilation aborted!

[jemc]

FYI, "does not dominate all uses" basically translates to "this variable gets used in some branch where it has not actually been assigned".
Here's a talk in which the speaker explains how LLVM Dominator Trees work: https://www.youtube.com/watch?v=bNV18Wy-J0U

[jemc]

So the error message is saying that we generated code to allocate a thing, and somewhere else we generated code to use that allocated pointer, but that was in an execution branch where it was not actually ever assigned.

[jemc]

@SeanTAllen - So there's basically two possibilities:

• :one: Our custom optimization passes are mishandling some edge case and causing the LLVM IR to be transformed in an invalid way (this is my bet right now). If this is the case, the issue should become fixed if you comment-out one or more of our custom optimization passes on these lines: https://github.com/ponylang/ponyc/blob/abfa64f8b0e4335f43a175e7267b1556806d5571/src/libponyc/codegen/genopt.cc#L1361-L1368
• :two: We are generating invalid code in the codegen pass. If this is the case, then if you turn on VerifyOutput but turn off all optimizations (basically, ponyc running in --debug mode), you'd still see the same VerifyOutput error you pasted above.

[SeanTAllen]

@jemc I do not get the VerifyOutput error when running ponyc --debug. For now I am assuming that idea number 2 is not the problem.

[SeanTAllen]

@jemc turning off all our pony_specific passes does not fix the issue either.

[SeanTAllen]

With "VerifyOutput" on.
With all Pony specific optimizations off.
And with the following turned off:

  if(!c->opt->library)
   lpm.run(*m);

that is around line 1428 of genopt.cc then we do not get an error of any sort and successfully compile the program.

[SeanTAllen]

At pmb.OptLevel = 1; there's no issue. Once we go to 2 or higher, there's an issue

[SeanTAllen]

Not populating the module pass manager ALSO fixes the issue.

pmb.populateModulePassManager(mpm);

Perhaps an interaction between module pass and link time pass?

Turning either one of them (doesn't matter which) off, "solves" the issue.

[SeanTAllen]

Running the module pass after the link pass also "solves" the issue:

  if(!c->opt->library)
    lpm.run(*m);

  mpm.run(*m);

Note, that is the ONLY change needed to genopt.cc to get the example code compiling.

[SeanTAllen]

In the LLVM 7 MPM code that we are executing there is:

MPM.add(createInstSimplifyLegacyPass());

If that isn't run then with everything else as is, we are fine and there's no crash.
Given that reordering mpm and lpm also fixes the problem then it would see that InstSimplifyLegacyPass interacts poorly with something that is happening in the LLVM lpm code that we end up executing.

It's getting late here so I'm putting this down for now. I'll pick this up later and try to figure out what is being run in LPM that is interacting poorly with the above MPM pass.

[SeanTAllen]

@lenary offered some advice on Twitter:

https://twitter.com/lenary/status/1152904673638199296
https://twitter.com/lenary/status/1152904894694793222
https://twitter.com/lenary/status/1152905142641070085

[SeanTAllen]

It appears that on the optimization side, we are interacting with:

PM.add(createMemCpyOptPass());

Without that pass, life is also golden.

[SeanTAllen]

@EpicEric have you had any luck creating a more minimal example?

[EpicEric]

No, the last I touched anything in this issue was using git bisect.

I can try to come up with a minimal example in the weekend.

[SeanTAllen]

@EpicEric if you can, it would be very handy. at this point we know what bits are interacting oddly but not what the code that causes it.

[EpicEric]

Found a (deceptively simple) minimal example:

use "collections"

class Bar

actor Main
  new create(env: Env) =>
    Map[String, (U32, Bar, Bar)].update("hello", (10, Bar, Bar))

A few notes:

• Removing U32 or any of the Bar from the value tuple type, or changing a Bar to a U32, fixes the crash.
• Changing Bar to a different A ref type, or reordering the tuple types, stilll crashes the compiler.

@SeanTAllen Please test this example if you would, as you might have a different setup than mine.

[mshockwave]

So after some dirty hacking, I've confirmed this is the function that has problem:
collections_HashMap_collections_HashMap_String_val_collections_HashMap_I32_val_u2_pony_kafka_KafkaBrokerConnection_tag_None_val_collections_HashEq_I32_val_val_ref_collections_HashEq_String_val_val_val_t3_collections_HashMap_String_val_collections_HashSet_I32_val_collections_HashEq_I32_val_val_iso_collections_HashEq_String_val_val_val_I32_val_collections_HashSet_pony_kafka_KafkaProducer_tag_collections_HashIs_pony_kafka_KafkaProducer_tag_val_ref_collections_HashIs_collections_HashMap_String_val_collections_HashMap_I32_val_u2_pony_kafka_KafkaBrokerConnection_tag_None_val_collections_HashEq_I32_val_val_ref_collections_HashEq_String_val_val_val_val_ref_update_o3oioo
So I think @EpicEric 's reduced example kinda make sense, because although I'm not familiar with the name mangling rules, I think the function is related to some map.
I've also confirmed that the problem is caused by MemCpy Optimization(llvm/lib/Transforms/Scalar/MemCpyOptimizer.cpp). I haven't dig into the implementation but I think we're pretty closed

[mshockwave]

Also, just an off-topic thing while I was debugging this problem: we definitely need to find a way to supply command line options of ponyc to LLVM (i.e. calling the llvm::cl::ParseCommandLineOptions(argc, argv) function). Otherwise we can not use any of the LLVM command line option from ponyc.

[mshockwave]

Another off-topic thing is that during my investigation, I find more places that violate the LLVM verifier. Most of them are related to DebugInfo, especially DISubProgram. I probably will post it in a new issue thread.

[SeanTAllen]

@mshockwave there might be an open issue related to DebugInfo creation. It's a long standing issue to get fixed. If you can't find the issue (it would be an old one), please do open an issue for it.

[mshockwave]

I've finally found the root cause for the verifier error (and hopefully the root cause of this issue ticket). I will write down the details in some other place, but here is the short version:
First, here was the original program:

%ctx = call i8* @pony_ctx()
...
%5 = load i8* %src_ptr
%6 = call i8* @pony_alloc_small(i8* %ctx, i32 0)
%dst_ptr = GEP %6, ...
%8 = store i8 %5, i8* %dst_ptr

And here are the steps that create the bug:

1. The MemCpyOptimization pass tried to hoist %8 over %6 because it think %6 will clobber (i.e. modify the memory pointed by the pointer) %src_ptr.
2. During the hoisting of %8, since %dst_ptr is used by %8, it will also be hoisted over %6, and thus created a used-before-defined bug.

There are two problems in this sequence:

1. Why does LLVM think %6, which is effectively just a malloc, will alias %src_ptr, which is simply pointing an application memory?
2. Why does MemCpyOptimization not finding the use-def chain conflict during hoisting?

For problem 1, it turns out that the attribute attached on @pony_alloc_small impose that this function's alias behavior not only depends on its pointer argument, but also stricter than usual cases. And since its argument, %ctx is created by @pony_ctx, there is no attribute attached to help it to defense its alias behavior, so eventually LLVM pessimistically think %ctx must alias with %src_ptr.

For problem 2, I think there is a problem in MemCpyOptimization in its code motion implementation. My intuition will be that they should add more sanity checks before aggressively hoisting code.

But at the meantime, I think we should think this: How to make @pony_ctx and @pony_small_alloc more distinguishable from other application memory? How do we tell LLVM that most of the time these two functions will not clobber other application memory?

[lenary]

Potentially a few things are going on.

1. Looking at https://github.com/ponylang/ponyc/blob/e55db85d928ce34386edd39b3c135977aba5eb65/src/libponyrt/pony.h#L295 I'm not sure that clang understands __attribute__((malloc)), but it does seem to explicitly support __attribute((alloc_size(...))) which might allow you to teach the compiler what's going on better. See https://clang.llvm.org/docs/AttributeReference.html#alloc-size

2. What will probably make the largest difference is showing the attributes that LLVM IR has on the declarations of @pony_ctx and @pony_alloc_small, which is what the pass will use when doing reasoning about these functions.

It is probably also worth filing an LLVM bug about this, if you have a reduced testcase you can attach to the ticket.

[mshockwave]

@lenary I also saw that libponyrt file. However:

1. __attribute__((malloc)) will lead to adding noalias on the return value, it won't add any attributes on arguments. The __attribute((alloc_size(...))) only deal with the return value, too. Thus I don't think these two attribute will tackle the root cause, which was primarily caused by attributes on arguments, I found earlier. Nevertheless, I do think about adding attributes on the return value for pony_ctx (which is one of the arguments for pony_alloc_small). For example, using the noalias and alias_scope attributes to separate pony's context memory with other application memory.
2. The attributes attached to arguments of pony_alloc_small is done by the code here. We can see that the code add inaccessiblemem_or_argmemonly attribute to pointer argument of pony_alloc_small: that's the attribute which will make alias analysis imposing stricter rules as I mentioned earlier. (I know it's a little bit weird that even we have header files for compiler runtime (i.e. libponyrt/pony.h), currently ponyc still construct LLVM IR for runtime functions by itself)

For the MemCpyOpt bug, I will take a deeper look into and see if we can file an issue or provide a fix to upstream LLVM :-)

[mshockwave]

As a follow up of the potential bug in MemCpyOpt, here is the LLVM IR that can trigger it:

; ModuleID = './bug.ll'
target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-apple-macosx10.14.0"

%my_struct = type { i8, i32 }

; Function Attrs: inaccessiblemem_or_argmemonly
declare noalias i8* @my_malloc(%my_struct*) #0

define void @my_func(%my_struct* %0) {
entry:
  %1 = load %my_struct, %my_struct* %0
  %2 = call i8* @my_malloc(%my_struct* %0)
  %3 = bitcast i8* %2 to %my_struct*
  store %my_struct %1, %my_struct* %3
  ret void
}

attributes #0 = { inaccessiblemem_or_argmemonly }

!llvm.module.flags = !{!0, !1, !2}
!llvm.ident = !{!3}

!0 = !{i32 2, !"SDK Version", [2 x i32] [i32 10, i32 14]}
!1 = !{i32 1, !"wchar_size", i32 4}
!2 = !{i32 7, !"PIC Level", i32 2}
!3 = !{!"Apple LLVM version 10.0.1 (clang-1001.0.46.4)"}

If you run with

opt -memcpyopt ./bug.ll

You will get a similar verifier error message as the one in this issue.

I'll file a bug in LLVM's Bugzilla and try to come up with a fix soon.

[jemc]

Nice work with the minimal repro!

[mshockwave]

I think it's a good time to wrap up this issue: My patch works correctly on the example program here and passes all the existing tests.
The biggest problem now is that since this fix is on the LLVM side, how do we propagate it back to ponyc? Currently we don't use custom-built LLVM, so should we just disable MemCpyOpt pass for now until the patch is landed in upstream LLVM?

[SeanTAllen]

Pushing conversation on this to next week.

[mshockwave]

@SeanTAllen pinging this issue. Is there any plan on discussing this issue during sync up meeting?

[SeanTAllen]

@mshockwave we decided a couple of weeks back that in general, we are:

• continuing to move towards using a vendored LLVM for everything, but particularly releases. until we are there the rest of this doesn't matter

once we are doing releases using a vendored LLVM, any patches like this will be applied at build time.

We need to create an issue for working on applying patches as part of the make process.

We are generally hoping that LLVM 9 support is finished soon and hopefully, this particular issue doesn't exist anymore. That said, @kulibali is working on switching us over to using cmake for all builds so any work on patching should probably be done after that (as it would perhaps need to be repeated), best to discuss that with @kulibali.

@kulibali has currently paused the cmake work because I've been doing a lot of work around messing with CI and build process as part of the move to vendored.

@mshockwave would you be interested in lending a hand in either of these ways:

• Helping with the LLVM 9 work
• Figuring out with @kulibali the best path forward on the "patch vendored LLVM" work as it relates to make and cmake

[lenary]

@mshockwave you should definitely ping that patch on review, and maybe point out that it breaks Pony (which may make people wake up).

That patch has not landed in LLVM 9.0, so you're still going to have to manually apply this patch after the upgrade to 9.0.

[mshockwave]

@mshockwave we decided a couple of weeks back that in general, we are:

continuing to move towards using a vendored LLVM for everything, but particularly releases. until we are there the rest of this doesn't matter

once we are doing releases using a vendored LLVM, any patches like this will be applied at build time.

We need to create an issue for working on applying patches as part of the make process.

Just want to double check: "vendored" here means using the upstream LLVM source code tree, right?

I'm generally happy to see all these changes happen. Both the cmake part and the adoption of vendored LLVM + patching.

@mshockwave would you be interested in lending a hand in either of these ways:

* Helping with the LLVM 9 work

Yes, I'm happy to help that.

* Figuring out with @kulibali the best path forward on the "patch vendored LLVM" work as it relates to make and cmake

Sure, I believe it would be an interesting topic

[mshockwave]

@lenary Yes I will ping on the Phabricator and connecting it with ponyc. At the same time, I'm contacting LLVM Weekly to see if they can put a heads-up regarding that review in the issue next week.

[lenary]

@mshockwave that sounds like a sensible idea regarding llvm weekly.

I think "vendoring" means pony ships with their own pony-specific copy of LLVM, like rust currently does, rather than relying on the version of an LLVM somewhere else in the system.

[SeanTAllen]

Vendoring means using the LLVM that we have pulled in as a git-submodule.

See: https://github.com/ponylang/ponyc/tree/master/lib/llvm

[kulibali]

Any help with LLVM 9 (#3320) would be welcome, as I don't have a lot of time to work on it.

[mshockwave]

FYI: Good news my patch regarding MemCpyOpt fix just got accepted. It will be in the next LLVM release.

[SeanTAllen]

Awesome.

[SeanTAllen]

@mshockwave would you be interested in helping to get us up to date with LLVM support?

[mshockwave]

@SeanTAllen yes I am interested. I will cooperate with @kulibali on issue #3320

[SeanTAllen]

@mshockwave you are awesome. thanks.

[lenary]

I have added this patch to the list of changes to be backported to LLVM 9.0.1: PR43974.

[lenary]

Update: the fix has been merged into the 9.0.1 branch. I'm still not sure the timeline of the 9.0.1 release.

[SeanTAllen]

Awesome. Thanks for the update @lenary.

[lenary]

9.0.1-final is scheduled for 9 Dec 2019

[SeanTAllen]

@EpicEric this is fixed for me on master when using a ponyc compiler built using the vendored LLVM. can you confirm?

• make -f Makefile-lib-llvm default_pic=true -j4

is how I am building said ponyc compiler.

[EpicEric]

Confirming that current master doesn't crash with vendored LLVM.