|
00:01
TimToady joined
|
|||
| MasterDuke | .ask brrt any idea why adding `(template: gt_i (gt $1 $2))` to src/jit/core.expr would cause the NQP build to segfault at src/jit/tile.c:127? it doesn't segfault with that commented out | 00:54 | |
| yoleaux | MasterDuke: I'll pass your message to brrt. | ||
|
01:00
Ven joined
01:48
ilbot3 joined
02:36
bisectable6 joined
04:47
leedo joined
09:48
robertle joined
10:27
brrt joined
10:37
Ven joined
|
|||
| brrt | . | 10:47 | |
| yoleaux | 00:54Z <MasterDuke> brrt: any idea why adding `(template: gt_i (gt $1 $2))` to src/jit/core.expr would cause the NQP build to segfault at src/jit/tile.c:127? it doesn't segfault with that commented out | ||
| brrt | .tell MasterDuke i'll look into it | ||
| yoleaux | brrt: I'll pass your message to MasterDuke. | ||
|
10:47
Ven_ joined
|
|||
| Geth | MoarVM/even-moar-jit: c2eaa53352 | (Bart Wiegmans)++ | src/jit/linear_scan.c Fix cycle break ordering In ordering registers for function calls, it may occur that there is a cycle in the transfer graph. These cycles must be broken somehow. I had used a stack, but that would cause the cycle to be broken 'in reverse', which would only be a problem if there were more than two registers involved and therefore went unnoticed. The simpler solution - walking the chain of transfers 'backwards' until we reach the starting point - is actually correct. |
10:53 | |
| MoarVM/even-moar-jit: 4bd21caaac | (Bart Wiegmans)++ | src/jit/core.expr Add elems instruction to the expr JIT, again This was broken due to the broken cycle breaker, but now that cycle breaking is fixed, this can be reactivated. |
|||
| timotimo | yey | ||
|
10:54
Ven_ joined
11:01
Ven_ joined
|
|||
| brrt | oh, i see why that breaks MasterDuke | 11:06 | |
| that's because GT does not yield a register | 11:07 | ||
|
11:07
Ven_ joined
|
|||
| brrt | but a flag | 11:08 | |
| and the flag has to be converted to an integer by something called 'FLAGVAL' | |||
|
11:18
AlexDaniel joined
11:21
Ven_ joined
|
|||
| Geth | MoarVM/even-moar-jit: ada4c471c0 | (Bart Wiegmans)++ | 5 files Add FLAGVAL op and implement gt_i Expr ops like GT, LE, etc. yields 'flags', not register values (meaning on x64 they set bits in the flag register), which can be directly used by conditional operations (e.g. conditional branches). But MoarVM-level 'gt_i' ops etc. need to set the result of the comparison into an integer value. The FLAGVAL expr op is intended to intermediate between the two representations. |
11:27 | |
| MoarVM/even-moar-jit: fcff787615 | (Bart Wiegmans)++ | 2 files Add atpos_o Now works after cycle breaking has been fixed |
11:32 | ||
MoarVM/even-moar-jit: 8 commits pushed by (Timo Paulssen)++, (Jonathan Worthington)++, (Bart Wiegmans)++
|
11:34 | ||
| brrt | gethow still triggers a bug | 11:46 | |
| but it's a different one, at least | |||
| timotimo | interesting | 11:47 | |
| how about iter? | |||
| brrt | that's presumably the s-expr parser bug | ||
| i'll look at that later | 11:48 | ||
| timotimo | oh, interesting | ||
| brrt | i think it's the 'hole' problem | 11:52 | |
| matter of fact, fairly sure it is | |||
| okay, i need to think a bit on how to fix it because it's subtle | 11:53 | ||
|
12:00
Ven joined
12:29
nebuchadnezzar joined
13:05
Ven joined
13:08
nebuchadnezzar joined
|
|||
| Geth | MoarVM/even-moar-jit: d7c4a05a9b | (Bart Wiegmans)++ | 2 files Values in holes are not live If a live range contains a hole arround the CALL, it isn't spilled, and if the hole extends arround the ARGLIST, it isn't used either, so it is completely free. This adds the gethow bug (timotimo++) |
13:52 | |
|
13:53
brrt joined
|
|||
| brrt | ugh, *fixes the gethow bug | 13:53 | |
| ilmari | quick, amend and force-push before anyone notices | 14:01 | |
| MasterDuke | .tell brrt i just pulled your recent commits and then tried adding ge_i, lt_i, le_i, eq_i, and ne_i. however, lt_i and eq_i break the nqp build | 14:11 | |
| yoleaux | MasterDuke: I'll pass your message to brrt. | ||
|
14:24
committable6 joined
|
|||
| MasterDuke | .tell brrt and ne_i does weird stuff to the rakudo build. if finishes, but with a ton of different lines of output like this: `Useless use of $dist in sink context (lines 53289, 53342)` | 14:41 | |
| yoleaux | MasterDuke: I'll pass your message to brrt. | ||
| MasterDuke | .tell brrt fwiw, with ge_i and le_i added rakudo almost passes a spectest, a couple failures in t/spec/S05-mass/rx.t that all seem to be caused by `Cannot find method 'rxtype' on object of type NQPMu` | 15:02 | |
| yoleaux | MasterDuke: I'll pass your message to brrt. | ||
| MasterDuke | .tell brrt another update. if i only add le_i all spectests pass. | 15:37 | |
| yoleaux | MasterDuke: I'll pass your message to brrt. | ||
|
15:45
Zoffix joined
16:30
zakharyas joined
17:03
zakharyas joined
|
|||
| Geth | MoarVM/master: 9 commits pushed by (Pawel Murias)++, (Jimmy Zhuo)++
|
17:52 | |
|
17:56
domidumont joined
18:02
domidumont joined
18:24
AlexDani` joined
18:32
brrt joined
|
|||
| brrt | jit-bisect will surely tell me what is wrong :-) | 18:37 | |
| yoleaux | 14:11Z <MasterDuke> brrt: i just pulled your recent commits and then tried adding ge_i, lt_i, le_i, eq_i, and ne_i. however, lt_i and eq_i break the nqp build | ||
| 14:41Z <MasterDuke> brrt: and ne_i does weird stuff to the rakudo build. if finishes, but with a ton of different lines of output like this: `Useless use of $dist in sink context (lines 53289, 53342)` | |||
| 15:02Z <MasterDuke> brrt: fwiw, with ge_i and le_i added rakudo almost passes a spectest, a couple failures in t/spec/S05-mass/rx.t that all seem to be caused by `Cannot find method 'rxtype' on object of type NQPMu` | |||
| 15:37Z <MasterDuke> brrt: another update. if i only add le_i all spectests pass. | |||
| brrt | eq_i breaks it fastest :-) | 18:38 | |
| a cast is clearly missing in the eq_i | 18:52 | ||
| 90% certainty that it is the problem | 18:54 | ||
| MasterDuke | i thought those would be simple enough i could try to figure out what was going wrong...but i was wrong | 18:57 | |
| brrt | well | 19:16 | |
| there is a tool for that | |||
| it's called jit-bisect.pl | |||
| run it with your command like so: | |||
| perl ~/MoarVM/tools/jit-bisect.pl -- your_command --with --args | 19:17 | ||
| MasterDuke | nqp: say(nqp::iseq_i(2**62, 2**60-1)) | 19:24 | |
| camelia | 0 | ||
| MasterDuke | nqp: say(nqp::iseq_i(2**62, 2**62-1)) | ||
| camelia | 1 | ||
| MasterDuke | m: use nqp; say(nqp::iseq_i(2**62, 2**62-1)) | 19:26 | |
| camelia | 0 | ||
|
19:48
zakharyas joined
20:28
brrt joined
20:30
brrt left,
brrt joined
|
|||
| samcv | i think i've gotten a kinda hackish way to resolve linking scripts to their actual .so files | 22:55 | |
| trying now to install some nativecall using modules | 22:56 | ||
|
23:04
Ven joined
|
|||
| samcv | it loads the new library the only thing is it doesn't seem to save the new library path so it seems to pass most of the Readline module tests and then eventually segfaults | 23:11 | |
| Geth | MoarVM/nativecall_script: 74c581b326 | (Samantha McVey)++ | src/core/nativecall.c Stash |
23:15 | |
| MoarVM/nativecall_script: c48cb45a1a | (Samantha McVey)++ | src/core/nativecall.c stash2 |
|||
| MoarVM/nativecall_script: 06d0de2fd3 | (Samantha McVey)++ | src/core/nativecall.c If we can't load the library, check if it's a ldscript If it is a basic ldscript which contains 'GROUP ( /usr/lib/actuallib.so )' then we attempt to load that library instead. We read the file referred to in the lderror and then search for GROUP ( and then try and load that file. |
23:27 | ||
| samcv | oops | ||
| ugh how did that happen. i typed what remote to go to :| | 23:28 | ||
| samcv goes to delete that branch now | |||
| not sure if i can though. heh | 23:29 | ||
| not sure what's wrong with my git. i designated the remote with every push i did. but somehow it decided to ignore it on one of my pushes. | 23:31 | ||