Upstream merge #153
Merged
Upstream merge #153
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Bump copyright year in `LICENSE`
Update to SML/NJ 110.99 libraries
…libs Update mlnlffigen to new SML/NJ Library PP functions
Create and update pages for 20210117 release
Link additional binary packages
fix option '-pi-style pie'
mlton/Makefile writes the output to "$(MLTON_OUTPUT)-polyml", but Makefile tries to copy it from "mlton-polyml", while MLTON_OUTPUT is "$(MLTON)-compile" by default
'make update' failed with this message: /bin/sh: 12: Syntax error: end of file unexpected (expecting "then")
* Correct path in `make polyml-mlton` in `./Makefile` * Remove duplicate `if` in `./Makefile.binary`
Add support for DESTDIR in Makefile.binary
The "shortest stem" rule for choosing a pattern rule was added in GNU Make 3.82 (https://lists.gnu.org/archive/html/info-gnu/2010-07/msg00023.html), but MacOS is stuck on the (ancient) GNU Make 3.81, which uses definition order priority.
Use static pattern rule for bootstrap compilation
Use `-{enable-disable}-pass '.*:typeCheck'` to control type-checking of ILs in
individual simplify passes, simplify pipelines, and translation passes.
The overall default behavior is the same, but rather than type checking at the
beginning and end of each IL simplify pipeline, we now type check at the end of
each translation pass and the end of each IL simplify pipeline. (For example,
previously, we type checked at the beginning and end of `ssaSimplify`, but now
we type check at the end of `closureConvert` and the end of `ssaSimplify` (and
not at the beginning of `ssaSimplify`).)
In addition, it is possible to enable type checking for exactly one simplify
pass (e.g., `-enable-pass 'constantPropagation:typeCheck'`) without needing to
type check every pass.
The `stackTop` and `stackBottom` fields are accessed infrequently by the GC itself, so there should be little penalty to making them `volatile`. They are synchronized with `currentThread->stack` at GC entry and exit.
In particular, the return address stack offset is volatile when time profiling; it is important that the return address be flushed to the stack before the adjusted stack top is flushed to `struct GC_state`.
Currently unused, added for completeness with `Offset` and `StackOffset` variants.
Fix bug with `-profile time` leading to a segmentation fault.
…codegens The x86 and x86-64 calling conventions require 8- and 16-bit arguments to be passed as 32-bit values (on the stack for x86 and in registers for x86-64). The x86-64 SysV ABI doesn't specify the contents of the upper bits for such argument extensions. Both gcc and clang sign- or zero-extend according to the declared type of the argument. Furthermore, clang assumes such a type-directed extension of incoming arguments (and can optimize accordingly). See https://stackoverflow.com/questions/36706721/is-a-sign-or-zero-extension-required-when-adding-a-32bit-offset-to-a-pointer-for/36760539#36760539. For example, consider the function: unsigned int s8_to_u32(signed char x) { return (unsigned int)x; } clang will optimize to movl %edi, %eax while gcc will optimize to movsbl %dil, %eax For slightly increased clang compatibility, the x86 and amd64 codegens are modified to emit either a signed or zero extension conditional on the declared type of the argument in the C function's prototype (rather than unconditionally using a zero extension).
Various ABIs may require argument or return values to be sign- or zero-extended according to the declared type of the argument. LLVM accomodates this via the `signext` and `zeroext` parameter attributes.
…amd64-and-llvm-codegens Calling convention fix for amd64 and llvm codegens
Use `msys2/setup-msys2` and `shell: msys2 {0}` to share CI steps between all
platforms.
Fix and consolidate Windows CI
Upload build artifacts in CI
shwestrick
approved these changes
May 21, 2022
|
An The |
|
Excellent, thanks. We've been putting Perhaps at some point I'll go through an look more carefully at where the annotation is and isn't needed. But anyway, this pull looks ready to go. Merging now! 🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Merge MLton/mlton upstream changes to master