| *** tpb <[email protected]> has joined #yosys | 00:00 | |
| *** strobo <[email protected]> has quit IRC (Read error: Connection reset by peer) | 10:02 | |
| *** strobo <[email protected]> has joined #yosys | 10:03 | |
| *** nak <nak!~nak@yosys/nak> has quit IRC (Quit: Bye) | 11:02 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has quit IRC (Read error: Connection reset by peer) | 13:33 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has joined #yosys | 13:34 | |
| *** bjorkintosh <bjorkintosh!~bjork@user/bjorkintosh> has quit IRC (Quit: Leaving) | 16:16 | |
| *** strobo <[email protected]> has quit IRC (Read error: Connection reset by peer) | 16:29 | |
| *** strobo <[email protected]> has joined #yosys | 16:29 | |
| *** Guest22 <[email protected]> has joined #yosys | 17:36 | |
| povik | new toymap results | 17:59 |
|---|---|---|
| povik | https://github.com/povik/toymap/commit/d47a41bb473 | 17:59 |
| povik | fixed a severe case of overconstraining the lut depths, and copied over some more abc heuristics | 18:00 |
| povik | i think i will look into aig preprocessing next | 18:00 |
| povik | would ping whitequark if they were here... | 18:01 |
| povik | hah, github's rich diff is pretty good for viewing this | 18:09 |
| povik | https://github.com/povik/toymap/commit/d47a41bb473?diff=unified&short_path=b335630 | 18:09 |
| *** derekn <[email protected]> has quit IRC (Ping timeout: 244 seconds) | 18:39 | |
| dxld | povik: super excited to see such a small implementation get so close to what abc can do :D | 18:43 |
| *** derekn <[email protected]> has joined #yosys | 18:43 | |
| dxld | I'm not familiar with the details here, could you shed some light on whether toymap would completely replace abc or are there other areas in yosys where it's still used? | 18:43 |
| dxld | (I want to get rid of abc because it's such a huge unmaintainable pile of complexity; I've had the displeasure of trying to figure out how to get it working on all the "weird" architectures in Debian ;) | 18:48 |
| povik | i mean, i have no idea what 98 % of abc commands do | 18:58 |
| povik | though i guess most people ever invoke abc from yosys for techmapping, which is in scope for toymap (being a toy though!) | 18:59 |
| povik | you are free to run abc from yosys with custom abc scripts | 19:03 |
| Adrien[m] | corecode: at least Interesting points of potential behaviour of tools to take care of, good for not getting trapped in trivial issues because of inexperience with these tools | 19:03 |
| povik | so in a way nothing can ever replace it... | 19:03 |
| *** Wolfvak <Wolfvak!~Wolfvak@user/wolfvak> has quit IRC (Remote host closed the connection) | 19:09 | |
| *** whitequark[cis] <whitequark[cis]!whitequa_1@2a01:4f8:c012:5b7:0:1:0:4> has joined #yosys | 19:15 | |
| whitequark[cis] | <dxld> "(I want to get rid of abc..." <- abc basically doesn't work on 64-bit platforms | 19:15 |
| whitequark[cis] | that's a load bearing "basically"; the actual issue is that it's making assumptions incompatible with ASLR on macOS | 19:15 |
| whitequark[cis] | and there's no apparent way to fix that | 19:15 |
| whitequark[cis] | to clarify, the assumptions it's making are incorrect everywhere (as far as i know) but on macOS it happens to randomly segfault and the only solution for that we have is "run the thing again" | 19:16 |
| dxld | povik: I'm not too worried about custom abc scripts, nobody understands abc so nobody is likely to use those :] | 19:16 |
| whitequark[cis] | anyway, replacing abc wouldn't mean literally making an API-compatible application; it would mean building something much simpler and smaller that just does LUT mapping for FPGAs | 19:17 |
| dxld | whitequark[cis]: sounds like a job for qemu-user to me honestly :P | 19:17 |
| whitequark[cis] | and maybe sequential synthesis eventually | 19:17 |
| whitequark[cis] | dxld: one potential solution we've seriously thought about is building it for wasm, then using wasm2c to turn it back to C, then using that in yosys | 19:17 |
| whitequark[cis] | this sounds borderline absurd but you get almost the full performance | 19:17 |
| whitequark[cis] | it's basically an automated way to transform C code to safe(ish) C code :D | 19:18 |
| *** xiretza[cis] <xiretza[cis]!xiretzaxir@2a01:4f8:c012:5b7:0:1:0:88> has joined #yosys | 19:18 | |
| xiretza[cis] | I'm surprised that doesn't just make it crash all the time rather than just sometimes | 19:18 |
| dxld | you do know what qemu-user lets you do right? it's literally a drop-in way to run i386 (or any qemu supported arch) executables on any other architecture | 19:18 |
| whitequark[cis] | i mean i don't think there would be obstacles to shipping that except someone has to add it to yosys | 19:18 |
| dxld | as long as it's an executable (and abc is) you're golden | 19:18 |
| whitequark[cis] | dxld: yeah i'm familiar | 19:19 |
| whitequark[cis] | and if it's not an executable you can write a tiny main() that calls the function you want | 19:19 |
| dxld | well yeah, but if yosys, say, called abc as a library you'd have to compile all of yosys as 32bit which obviously sucks much more than just having it confined to abc | 19:20 |
| whitequark[cis] | it doesn't call it as a library because of the random memory corruption that used to happen when it did | 19:20 |
| dxld | haha :) | 19:20 |
| whitequark[cis] | the support is there, you can enable it via an option | 19:20 |
| whitequark[cis] | yowasp-yosys does that | 19:21 |
| whitequark[cis] | because wasm is 32-bit (the compiler prefix i'm using anyway) it doesn't tickle those bugs at least | 19:21 |
| whitequark[cis] | though... i tried building abc for wasm not as a library within yosys (as a standalone executable) and it segfaults with a completely inscrutable backtrace | 19:21 |
| whitequark[cis] | i tried to make this work twice and decided to just implement what i want in some other way | 19:22 |
| dxld | anyway point is, povik, please keep doing what you're doing <3 | 19:22 |
| whitequark[cis] | (i wanted output redirection. i ended up using some really cursed freopen tricks. but that got it done in a day) | 19:22 |
| povik | dxld: i am happy you like it! though i can't promise it will ever amount to anything more serious | 19:29 |
| whitequark[cis] | I second dxld | 19:30 |
| povik | ok, that message applies to you too then :P | 19:30 |
| dxld | famous last words "just a hobby, won't be big and professional like gnu" :D | 19:30 |
| *** Wolfvak <Wolfvak!~Wolfvak@user/wolfvak> has joined #yosys | 19:42 | |
| jix | besides techmapping, abc is also used for formal verification from SBY, in particular the pdr command which implements pdr/ic3 (two names for the same algorithm) | 19:57 |
| *** bjorkintosh <bjorkintosh!~bjork@2600:1700:5400:c80:d6a5:b303:fb7e:c11f> has joined #yosys | 20:01 | |
| *** bjorkintosh <bjorkintosh!~bjork@user/bjorkintosh> has quit IRC (Client Quit) | 20:04 | |
| somlo | whitequark: not to mention that abc is broken on BE platforms (not sure if maybe that's what you meant when you said "64-bit platforms" earlier) | 20:10 |
| whitequark[cis] | no, that's a separate issue | 20:10 |
| whitequark[cis] | but might be related | 20:10 |
| *** V <V!~v@ircpuzzles/2022/april/winner/V> has quit IRC (Ping timeout: 240 seconds) | 20:11 | |
| jix | IIRC the endianness issue was it casting pointers to access the same data as differently sized int types, with the cast and the accesses not being close to each other, so really hard to even enumerate the places where that issue is present | 20:14 |
| jix | but that shouldn't be affected by ASLR | 20:15 |
| dxld | I wonder if there's a ASAN/UBSAN mode for detecting misaligned accesses? | 20:16 |
| dxld | and if not why not :) | 20:16 |
| dxld | uuh ubsan does actually seem to support that | 20:17 |
| jix | I don't think the accesses were misaligned, or at least even if they are not, the code would still be buggy | 20:18 |
| dxld | maybe this isn't as hopeless as we thought | 20:18 |
| dxld | the issue I have in mind is https://github.com/YosysHQ/yosys/issues/2645 | 20:19 |
| dxld | so yeah it was more complicated than simple alignment | 20:20 |
| dxld | whitequark[cis]: do you know any specific instances of code that break because of the macos ASLR? | 20:21 |
| dxld | or is there a tracking issue or something? | 20:21 |
| jix | dxld: yeah that's the same one I'm thinking of | 20:22 |
| whitequark[cis] | dxld: macos builds of yosys on CI fail spuriously because of it | 20:24 |
| whitequark[cis] | it's very annoying | 20:24 |
| whitequark[cis] | like, run the testsuite a few dozen times and it'll eventually segfault | 20:24 |
| whitequark[cis] | there's nothing i know of beyond that | 20:25 |
| povik | ah, so that's the reason for those fails | 20:25 |
| povik | indeed annoying | 20:25 |
| whitequark[cis] | ASLR causes breakage because abc makes incorrect assumptions about pointer bits | 20:25 |
| whitequark[cis] | I don't remember exactly which | 20:25 |
| *** V <V!~v@ircpuzzles/2022/april/winner/V> has joined #yosys | 20:26 | |
| dxld | capturing a coredump for one of these crashes might be a start for debugging this then | 20:28 |
| dxld | and I would try a build with all sanitizers I can get my mits on enabled as well for good measure | 20:30 |
| dxld | but given how crusty abc is maybe that'll be information overload :] | 20:31 |
| *** Wanda[cis] <Wanda[cis]!mwkmwkmwkm@2a01:4f8:c012:5b7:0:1:0:c> has joined #yosys | 20:36 | |
| Wanda[cis] | it also occasionally fails on linux for the same reason as on mac, it's just much rarer | 20:36 |
| *** acathla_ <[email protected]> has joined #yosys | 20:56 | |
| *** vup2 <[email protected]> has joined #yosys | 20:56 | |
| *** pi3 <[email protected]> has joined #yosys | 20:57 | |
| *** mwk_ <mwk_!~mwk@yosys/mwk> has joined #yosys | 20:57 | |
| *** krispaul <[email protected]> has joined #yosys | 20:58 | |
| *** lambda <[email protected]> has quit IRC (*.net *.split) | 21:02 | |
| *** acathla <[email protected]> has quit IRC (*.net *.split) | 21:02 | |
| *** kristianpaul <kristianpaul!~paul@user/kristianpaul> has quit IRC (*.net *.split) | 21:02 | |
| *** crzwdjk <[email protected]> has quit IRC (*.net *.split) | 21:02 | |
| *** vup <[email protected]> has quit IRC (*.net *.split) | 21:02 | |
| *** josuah <[email protected]> has quit IRC (*.net *.split) | 21:02 | |
| *** mwk <mwk!~mwk@yosys/mwk> has quit IRC (*.net *.split) | 21:02 | |
| *** lambda <[email protected]> has joined #yosys | 21:08 | |
| *** ec_ <ec_!~ec@gateway/tor-sasl/ec> has joined #yosys | 21:43 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Ping timeout: 246 seconds) | 21:46 | |
| *** nonchip <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 22:17 | |
| *** nonchip <[email protected]> has joined #yosys | 22:17 | |
| *** ec_ <ec_!~ec@gateway/tor-sasl/ec> has quit IRC (Remote host closed the connection) | 22:27 | |
| *** ec_ <ec_!~ec@gateway/tor-sasl/ec> has joined #yosys | 22:27 | |
| lofty | povik: looking at those results I'm reasonably confident you have a bug in your cut calculation code. | 23:39 |
| lofty | As in, you are likely producing fewer cuts than actually possible | 23:41 |
| lofty | I've been trying to figure out where it might be, but I'm not having too much luck from simply reading the code | 23:56 |
| lofty | But having greater LUT depth than ABC is a symptom of not enough cut variety. | 23:56 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!