Update LLVM to 14.0.3

[chalcolith]

This change updates our LLVM submodule to 14.0.3 and updates ponyc to compile with that version.

[ponylang-main]

Hi @kulibali,

The changelog - changed label was added to this pull request; all PRs with a changelog label need to have release notes included as part of the PR. If you haven't added release notes already, please do.

Release notes are added by creating a uniquely named file in the .release-notes directory. We suggest you call the file 4055.md to match the number of this pull request.

The basic format of the release notes (using markdown) should be:

## Title

End user description of changes, why it's important,
problems it solves etc.

If a breaking change, make sure to include 1 or more
examples what code would look like prior to this change
and how to update it to work after this change.

Thanks.

[chalcolith]

Ponyc compiles and all tests succeed except for small-finalisers and class-final. All the code changes I made are to optimization passes; when I disable those passes the tests still fail, so I'm assuming that something changed in LLVM that is affecting the generation of finalizers. I'm continuing to investigate.

[SeanTAllen]

We should also see if Windows debug builds stop hanging with this change.

[chalcolith]

Investigation so far:

Given a Pony program

use @pony_exitcode[None](code: I32)

class ClassFinal
  fun _final() =>
    @pony_exitcode(1)

actor Main
  new create(env: Env) =>
    ClassFinal

Using LLVM 13, the @Main_Dispatch() function ends with

  %6 = tail call i8* @pony_ctx() #2
  %7 = tail call i8* @pony_alloc_small_final(i8* %0, i32 0) #2
  %8 = bitcast i8* %7 to %ClassFinal_Desc**
  store %ClassFinal_Desc* @ClassFinal_Desc, %ClassFinal_Desc** %8, align 8

This is inlined from @Main_tag_create_oo(). If I understand correctly, we are allocating some memory for our instance of ClassFinal's finalizer, then writing a pointer to the global ClassFinal type descriptor to that memory.

Using LLVM 14 with optimizations on, the @Main_Dispatch() function ends with

  %6 = tail call i8* @pony_ctx() #2
  %7 = tail call i8* @pony_alloc_small_final(i8* %0, i32 0) #2

and there is no store of the ClassFinal type descriptor. So when we eventually get to running the finalizers, we have garbage instead of a pointer to the ClassFinal type descriptor.

If I change line 1365 in src/libponyc/codegen/genopt.cc to be pmb.OptLevel = 1 (or if I build in debug mode), the problem goes away (i.e. the store is now present). So now I'm investigating what optimizations are enabled at level 2 and above that are responsible for getting rid of the store.

[jemc]

Discussed during the sync call - I suspect if we link against the runtime bitcode the problem will be fixed, because we likely are tagging wrong attributes on one of our runtime functions. We need to tag the right attributes so that LLVM knows that the descriptor memory will be read from by our garbage collector, so that it won't try to optimize away the store to that memory.

That's what I suspect.

[chalcolith]

Looks like marking the store as volatile prevents it being removed.

[chalcolith]

Also on Linux I had to make copies of some of the LLVM C functions because they were marked as deprecated (I didn't see this at first because we don't error on warning in Windows). They were all expecting non-opaque pointers (which we supply), from which they could extract the LLVM type. LLVM has been deprecating these in favour of new functions (with a "2" added to their name) that can take opaque pointers, so you have to provide their types explicitly. So I made copies of the old functions (with a "_P" for Pony added to their names) that aren't marked deprecated.

Alternatively if we don't like this approach we could add a new C function that calls cast<PointerType>(Val->getType()->getScalarType())->getElementType() on an LLVMValueRef and returns the type, and then use that with the new "2" functions.

[chalcolith]

This is where we set the type descriptor store to be volatile.

[jemc]

I worry that marking the stores as volatile may be more of a workaround than a "real" solution, and it may potentially have performance effects.

That said, I don't have the answers about what the real solution would be.

@kulibali - did you try linking against the runtime bitcode and seeing if that resolves the issue?

[chalcolith]

Stupid typo in my comment above; using runtime bitcode DOES exhibit the problem. So it seems dead store elimination is a little agressive.

[SeanTAllen]

This seems like it might be worth opening an LLVM issue?

[chalcolith]

I believe we said last week that when Sean was recovered he would do some performance testing on this branch.

[jemc]

I'll spend some time poking around the LLVM git history.

[jemc]

I'll also try removing attributes from function declarations and call sites.

[chalcolith]

I have tracked down the breaking change to llvm/llvm-project@3cef3cf. I'll investigate further what we're doing with alias scopes.

[jemc]

Thanks for tracking down the commit.

Perhaps all that's needed is to remove the noalias_attr from our runtime function declarations for the runtime functions that allocate new objects.

Technically it's not true that there is no alias to these new objects, because we hold an alias to each of them in our heap's object map (which is the alias we use for running the finalizer). So removing that attribute is probably the "correct" way to solve this problem.

[chalcolith]

I have removed the noalias attribute from the runtime functions that allocate memory, and it works now without marking the store as volatile.

[jemc]

Glad that solved the issue!

I'm gonna clone this locally because there's one more thing I want to try - keeping the noalias attribute on some but not all of the functions, so we can still get this optimization in places where it's safe.

I'm going to do more reading in the Pony runtime to look for all the places we might dereference this pointer.

[jemc]

I've pushed a commit which reinstates most of the noalias attributes - all of them except the ones for pony_alloc_final* functions, as well as the deserialise function, which may include objects with finalisers.

This should help us keep the potential of LLVM being able to optimize away some heap allocations/stores which are not read from / captured, while still keeping correctness for objects with finalisers that may have specific finaliser effects to be run.