Implement bits necessary for SSA conversion in the compiler.#2
Closed
Implement bits necessary for SSA conversion in the compiler.#2
Conversation
ltratt
reviewed
Apr 25, 2019
| Rvalue::Place(p) => p.uses_vars_mut(), | ||
| Rvalue::Phi(ps) => { | ||
| let mut res = Vec::new(); | ||
| ps.iter_mut().fold(&mut res, |r, p| { |
Contributor
There was a problem hiding this comment.
Would this be clearer as a for loop?
Contributor
|
Is this PR still relevant? |
Contributor
Author
|
Nope, closing. |
ptersilie
added a commit
to ptersilie/yk
that referenced
this pull request
Nov 5, 2020
ptersilie
added a commit
to ptersilie/yk
that referenced
this pull request
Aug 31, 2022
ltratt
pushed a commit
to ltratt/yk
that referenced
this pull request
Apr 11, 2023
ptersilie
added a commit
to ptersilie/yk
that referenced
this pull request
Nov 23, 2023
ltratt
added a commit
to ltratt/yk
that referenced
this pull request
Feb 16, 2024
I've slowly come to realise that calls to `yk_promote` could (but don't
currently!) end up being in compiled in two different ways:
1. A literal call to `yk_promote_*`.
2. An inlined call to a side-band recording mechanism (e.g.
`PTWRITE`).
Because I hadn't teased these two apart in my mind, my previous attempt
had kind-of tried to merge the two together in one API. It's now clear
that was entirely misguided on my part.
This commit can be seen as partly undoing my previous attempt: literal
calls to `yk_promote_*` now record the data in `MTThread` which is a
thread local. However, when tracing stops, the promotion data is now
extracted from `MTThread` so it can safely be moved to another thread.
That means we can now handle ykjit#1 above: but we don't yet have an API that
can handle ykjit#2.
ltratt
added a commit
to ltratt/yk
that referenced
this pull request
Feb 16, 2024
I've slowly come to realise that calls to `yk_promote` could (but don't
currently!) end up being in compiled in two different ways:
1. A literal call to `yk_promote_*`.
2. An inlined call to a side-band recording mechanism (e.g.
`PTWRITE`).
Because I hadn't teased these two apart in my mind, my previous attempt
had kind-of tried to merge the two together in one API. It's now clear
that was entirely misguided on my part.
This commit can be seen as partly undoing my previous attempt: literal
calls to `yk_promote_*` now record the data in `MTThread` which is a
thread local. However, when tracing stops, the promotion data is now
extracted from `MTThread` so it can safely be moved to another thread.
That means we can now handle ykjit#1 above: but we don't yet have an API that
can handle ykjit#2.
ltratt
added a commit
to ltratt/yk
that referenced
this pull request
Dec 30, 2024
This commit does two things which might not seem immediately related:
1. It only prints out instructions which aren't tombstones are
equivalent.
2. It formats loads/store that inline ptradds as `load %x + y`
and `*(%x + y) = z` respectively.
In essence, before this commit we printed out all the "not used"
`PtrAdd` instructions, which meant that one got things like:
```
; %2: ...
...
; %3: ptr = ptr_add %2, 4
; %4: i8 = load %3
mov ...
```
In other words, such `PtrAdd`s didn't generate machine code. That's fine
but it turns out that we also printed some non-`PtrAdd`-but-dead
instructions too that the x64 backend's DCE had worked out. That's
actively misleading: it meant that some optimisations could be misread
as not being as effective as expected, because they would appear in
`jit-post-opt` even though they didn't generate code.
Step ykjit#2 above changes the formatting so that the example above is now
shown as the following in `jit-asm` output:
```
; %2: ...
...
; %4: i8 = load %2 + 4
mov ...
```
This means that the x64 backend produces JIT IR that isn't exactly
parseable -- at least not right now. It's also different than
`jit-post-opt`.
This initially felt a bit surprising to me, but then I realised that
`jit-asm` really means "backend specific output" and suddenly it made
more sense to me. The x64 backend *is* manipulating the trace IR in a
way that lets it generate better code and once upon a time I briefly
considered giving it a new IR before realising that I could repurpose
the trace IR. So if one views the `jit-asm` output as "another IR that
happens to mostly look the same as trace IR" it all makes sense -- at
least to me!
ltratt
added a commit
to ltratt/yk
that referenced
this pull request
Dec 30, 2024
This commit does two things which might not seem immediately related:
1. It only prints out instructions which aren't tombstones are
equivalent.
2. It formats loads/store that inline ptradds as `load %x + y`
and `*(%x + y) = z` respectively.
In essence, before this commit we printed out all the "not used"
`PtrAdd` instructions, which meant that one got things like:
```
; %2: ...
...
; %3: ptr = ptr_add %2, 4
; %4: i8 = load %3
mov ...
```
In other words, such `PtrAdd`s didn't generate machine code. That's fine
but it turns out that we also printed some non-`PtrAdd`-but-dead
instructions too that the x64 backend's DCE had worked out. That's
actively misleading: it meant that some optimisations could be misread
as not being as effective as expected, because they would appear in
`jit-post-opt` even though they didn't generate code.
Step ykjit#2 above changes the formatting so that the example above is now
shown as the following in `jit-asm` output:
```
; %2: ...
...
; %4: i8 = load %2 + 4
mov ...
```
This means that the x64 backend produces JIT IR that isn't exactly
parseable -- at least not right now. It's also different than
`jit-post-opt`.
This initially felt a bit surprising to me, but then I realised that
`jit-asm` really means "backend specific output" and suddenly it made
more sense to me. The x64 backend *is* manipulating the trace IR in a
way that lets it generate better code and once upon a time I briefly
considered giving it a new IR before realising that I could repurpose
the trace IR. So if one views the `jit-asm` output as "another IR that
happens to mostly look the same as trace IR" it all makes sense -- at
least to me!
ltratt
added a commit
to ltratt/yk
that referenced
this pull request
Jan 1, 2025
This commit does two things which might not seem immediately related:
1. It only prints out instructions which aren't tombstones or
equivalent.
2. It formats loads/store that inline ptradds as `load %x + y`
and `*(%x + y) = z` respectively.
In essence, before this commit we printed out all the "not used"
`PtrAdd` instructions, which meant that one got things like:
```
; %2: ...
...
; %3: ptr = ptr_add %2, 4
; %4: i8 = load %3
mov ...
```
In other words, such `PtrAdd`s didn't generate machine code. That's fine
but it turns out that we also printed some non-`PtrAdd`-but-dead
instructions too that the x64 backend's DCE had worked out. That's
actively misleading: it meant that some optimisations could be misread
as not being as effective as expected, because they would appear in
`jit-post-opt` even though they didn't generate code.
Step ykjit#2 above changes the formatting so that the example above is now
shown as the following in `jit-asm` output:
```
; %2: ...
...
; %4: i8 = load %2 + 4
mov ...
```
This means that the x64 backend produces JIT IR that isn't exactly
parseable -- at least not right now. It's also different than
`jit-post-opt`.
This initially felt a bit surprising to me, but then I realised that
`jit-asm` really means "backend specific output" and suddenly it made
more sense to me. The x64 backend *is* manipulating the trace IR in a
way that lets it generate better code and once upon a time I briefly
considered giving it a new IR before realising that I could repurpose
the trace IR. So if one views the `jit-asm` output as "another IR that
happens to mostly look the same as trace IR" it all makes sense -- at
least to me!
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This is the companion commit to:
softdevteam/ykrustc#14
Blocked by:
#1