Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unify the buildbot testing of the 3 packages #1

Merged
merged 2 commits into from
May 1, 2019
Merged

Unify the buildbot testing of the 3 packages #1

merged 2 commits into from
May 1, 2019

Conversation

ltratt
Copy link
Contributor

@ltratt ltratt commented Apr 16, 2019

Surprisingly this worked first time:

http://bencher12.soft-dev.org:8010/#/builders/2/builds/123

I've checked the log and it really is executing all of the tests we want. I should have bought a lottery ticket instead...

@vext01
Copy link
Contributor

vext01 commented Apr 17, 2019

I should have bought a lottery ticket instead...

Wanna go halfs next time?

This LGTM, but we need to add a bors config file (derive from the existing one in yktrace?) and then enable bors on this repo. I can help with this, but let's get the existing BB config into a repo before we break it ;)

bors bot added a commit to softdevteam/ykrustc that referenced this pull request Apr 23, 2019
13: Yk copy good builds r=ltratt a=vext01

Successful builds are tarred up and placed in /opt/ykrustc-bin-snapshots on the build master.

For now, store at most one archive, but we might change that in the future.

I've tested something very close to this (just without the chmod line in the buildbot script). It *should* work fine 😸 

```
$ ls -al /opt/ykrustc-bin-snapshots/
total 188948
drwxrwxr-x 2 root             buildbot_workers      4096 Apr 18 18:23 .
drwxr-xr-x 8 root             root                  4096 Apr 18 11:32 ..
-rwxrwxr-x 1 buildbot-worker4 buildbot-worker4 193469353 Apr 18 18:23 ykrustc-stage2-057d397c.tar.bz2
$ cd /tmp
$ tar jxf /opt/ykrustc-bin-snapshots/ykrustc-stage2-057d397c.tar.bz2 
$ cd ykrustc-stage2/
$ ls
bin  lib  VERSION
$ cat VERSION 
commit 057d397c982463d374f60e16f9b3863dc660e4f2
Author: Edd Barrett <[email protected]>
Date:   Thu Apr 18 12:04:20 2019 +0100

    Kill [install].
$ 
```

If you agree with this, then I suppose the next step is to try using the tarball in:
ykjit/yk#1

Co-authored-by: Edd Barrett <[email protected]>
@vext01
Copy link
Contributor

vext01 commented Apr 23, 2019

This LGTM, but we need to add a bors config file (derive from the existing one in yktrace?) and then enable bors on this repo. I can help with this, but let's get the existing BB config into a repo before we break it ;)

So the buildbot config is in git now, to move this forward:

@ltratt
Copy link
Contributor Author

ltratt commented Apr 23, 2019

Can I suggest you do those steps? You know each of them, and I don't, and so we'd probably do best to use your expertise. We can do that in this PR, and then ask someone else to review it, or we can merge this PR, and then you can open one doing those steps.

@vext01
Copy link
Contributor

vext01 commented Apr 23, 2019

I can do yeah.

@ltratt
Copy link
Contributor Author

ltratt commented Apr 23, 2019

Thanks! Would you prefer doing it in this PR or a fresh one?

@vext01
Copy link
Contributor

vext01 commented Apr 23, 2019

Let's do the first two points in the above bullet list in this PR. But let me clear my PR backlog first.

@ltratt
Copy link
Contributor Author

ltratt commented Apr 23, 2019

OK.

@vext01
Copy link
Contributor

vext01 commented Apr 23, 2019

bors ping

@bors
Copy link
Contributor

bors bot commented Apr 23, 2019

pong

@vext01
Copy link
Contributor

vext01 commented Apr 23, 2019

bors try

bors bot added a commit that referenced this pull request Apr 23, 2019
@vext01
Copy link
Contributor

vext01 commented Apr 23, 2019

bors try-

The snapshot PR was merged, so we might aswell do that here too.

@vext01
Copy link
Contributor

vext01 commented Apr 23, 2019

Last commit is a stab at using the snapshot tarballs for testing, but it wont work until this is merged:
softdevteam/ykrustc#15

@vext01
Copy link
Contributor

vext01 commented Apr 24, 2019

bors try

bors bot added a commit that referenced this pull request Apr 24, 2019
@vext01
Copy link
Contributor

vext01 commented Apr 24, 2019

bors try-

@vext01
Copy link
Contributor

vext01 commented Apr 24, 2019

bors try

bors bot added a commit that referenced this pull request Apr 24, 2019
@bors
Copy link
Contributor

bors bot commented Apr 24, 2019

try

Build failed

@vext01
Copy link
Contributor

vext01 commented Apr 24, 2019

Hrm, it appears cargo is still not installed...

@ltratt
Copy link
Contributor Author

ltratt commented Apr 24, 2019

I think the problem is export PATH=ykrustc-stage2/bin:/usr/bin:/bin -- shouldn't the first entry be /opt/...?

@vext01
Copy link
Contributor

vext01 commented Apr 24, 2019

The path is correct, there's only a tarball in /opt and we've already untarred it.

I've done post-mortem on the buildbot worker and build no cargo binary anywhere, so my guess is that the extended tools are a dependency of cargo install.

Trying using that instead...

@vext01
Copy link
Contributor

vext01 commented Apr 27, 2019

bors try

bors bot added a commit that referenced this pull request Apr 27, 2019
@bors
Copy link
Contributor

bors bot commented Apr 29, 2019

try

Build failed

@vext01
Copy link
Contributor

vext01 commented Apr 29, 2019

bors try

bors bot added a commit that referenced this pull request Apr 29, 2019
@bors
Copy link
Contributor

bors bot commented Apr 29, 2019

try

Build failed

@vext01
Copy link
Contributor

vext01 commented Apr 29, 2019

bors try

bors bot added a commit that referenced this pull request Apr 29, 2019
@bors
Copy link
Contributor

bors bot commented Apr 29, 2019

try

Build succeeded

@vext01
Copy link
Contributor

vext01 commented May 1, 2019

This is now ready for review, but since we've both pushed, we'd need a third-party. Assigning @jacob-hughes

@jacob-hughes
Copy link
Contributor

LGTM. Looks like you had some fun getting buildbot to work :) Feel free to squash.

We now test all packages and use a ykrustc binary snapshot.
@vext01
Copy link
Contributor

vext01 commented May 1, 2019

splat

@vext01
Copy link
Contributor

vext01 commented May 1, 2019

[don't forget to not use the green button! I can disable that after this merge]

@jacob-hughes
Copy link
Contributor

bors r+

bors bot added a commit that referenced this pull request May 1, 2019
1: Unify the buildbot testing of the 3 packages r=jacob-hughes a=ltratt

Surprisingly this worked first time:

  http://bencher12.soft-dev.org:8010/#/builders/2/builds/123

I've checked the log and it really is executing all of the tests we want. I should have bought a lottery ticket instead...

Co-authored-by: Laurence Tratt <[email protected]>
@bors
Copy link
Contributor

bors bot commented May 1, 2019

Build succeeded

@bors bors bot merged commit 137d1e0 into master May 1, 2019
@bors bors bot deleted the unify branch May 1, 2019 14:00
ptersilie added a commit to ptersilie/yk that referenced this pull request Aug 31, 2022
ltratt added a commit to ltratt/yk that referenced this pull request Apr 11, 2023
Convert the wiki to an mdbook.
@vext01 vext01 mentioned this pull request Nov 17, 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 3, 2024
In essence, this is the first commit towards moving us to "reverse code
generation by stealth". After JIT IR is optimised, this commit changes
things to a single reverse pass (previously we did a single forward
pass).

During that pass we:

  1. Identify `PtrAdd` instructions which can be inlined by
     `Load`/`Store`.
  2. Implicitly do a second round of dead-code elimination: currently
     this can only DCE some (not all!) `PtrAdd`s (those inlined by ykjit#1
     that aren't used elsewhere).

This turns out to be a much nicer way of optimised `PtrAdd`s than our
previous attempts: the code is neater (though that doesn't mean it's not
involved!) and it's also more effective because the register allocator
now has less things it thinks are alive. Overall, this speeds up
big_loop by about 10% because of the pressure it relieves from the
register allocator.

There is a lot of boring churn in tests because this forces us to
`black_box` lots of tests in the code generator. Honestly, we should
always have done that, but we got with it until now.
ltratt added a commit to ltratt/yk that referenced this pull request Dec 3, 2024
In essence, this is the first commit towards moving us to "reverse code
generation by stealth". After JIT IR is optimised, this commit changes
things to a single reverse pass (previously we did a single forward
pass).

During that pass we:

  1. Identify `PtrAdd` instructions which can be inlined by
     `Load`/`Store`.
  2. Implicitly do a second round of dead-code elimination: currently
     this can only DCE some (not all!) `PtrAdd`s (those inlined by ykjit#1
     that aren't used elsewhere).

This turns out to be a much nicer way of optimised `PtrAdd`s than our
previous attempts: the code is neater (though that doesn't mean it's not
involved!) and it's also more effective because the register allocator
now has less things it thinks are alive. Overall, this speeds up
big_loop by about 10% because of the pressure it relieves from the
register allocator.

There is a lot of boring churn in tests because this forces us to
`black_box` lots of tests in the code generator. Honestly, we should
always have done that, but we got with it until now.
ltratt added a commit to ltratt/yk that referenced this pull request Dec 4, 2024
In essence, this is the first commit towards moving us to "reverse code
generation by stealth". After JIT IR is optimised, this commit changes
things to a single reverse pass (previously we did a single forward
pass).

During that pass we:

  1. Identify `PtrAdd` instructions which can be inlined by
     `Load`/`Store`.
  2. Implicitly do a second round of dead-code elimination: currently
     this can only DCE some (not all!) `PtrAdd`s (those inlined by ykjit#1
     that aren't used elsewhere).

This turns out to be a much nicer way of optimised `PtrAdd`s than our
previous attempts: the code is neater (though that doesn't mean it's not
involved!) and it's also more effective because the register allocator
now has less things it thinks are alive. Overall, this speeds up
big_loop by about 10% because of the pressure it relieves from the
register allocator.

There is a lot of boring churn in tests because this forces us to
`black_box` lots of tests in the code generator. Honestly, we should
always have done that, but we got with it until now.
ltratt added a commit to ltratt/yk that referenced this pull request Dec 4, 2024
In essence, this is the first commit towards moving us to "reverse code
generation by stealth". After JIT IR is optimised, this commit changes
things to a single reverse pass (previously we did a single forward
pass).

During that pass we:

  1. Identify `PtrAdd` instructions which can be inlined by
     `Load`/`Store`.
  2. Implicitly do a second round of dead-code elimination: currently
     this can only DCE some (not all!) `PtrAdd`s (those inlined by ykjit#1
     that aren't used elsewhere).

This turns out to be a much nicer way of optimised `PtrAdd`s than our
previous attempts: the code is neater (though that doesn't mean it's not
involved!) and it's also more effective because the register allocator
now has less things it thinks are alive. Overall, this speeds up
big_loop by about 10% because of the pressure it relieves from the
register allocator.

There is a lot of boring churn in tests because this forces us to
`black_box` lots of tests in the code generator. Honestly, we should
always have done that, but we got with it until now.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants