June 2016 - ghc-devs - Haskell.org

topHandler03 failing now
by Edward Z. Yang 30 Jun '16

30 Jun '16

Hey thomie, You recently changed topHandler03 to not ignore output. Unfortunately, on my Arch Linux box this causes the test to fail: --- ./topHandler03.run/topHandler03.stderr.normalised 2016-06-30 10:30:56.423442132 -0700 +++ ./topHandler03.run/topHandler03.run.stderr.normalised 2016-06-30 10:30:56.423442132 -0700 @@ -1 +1 @@ -Terminated +/bin/sh: line 1: 7193 Terminated ./topHandler03 It seems the shell output behavior here varies. Edward

1 0

Trac spam
by Simon Peyton Jones 30 Jun '16

30 Jun '16

If someone could kill this spate of Trac spam, it’d be great. Simon

1 0

Using the GHC API to write an interpreter
by Christopher Done 28 Jun '16

28 Jun '16

I've been pondering how feasible it would be to: * Compile in stages a module with the byte code linker * Keep hold of the Core source * Interpret the Core AST within Haskell * When encountering built-in/primitives (or things from other libraries), we compile that Core term and link it as an HValue and then run it with the arguments expected. So () would be such a HValue, as would be "show" which in interpretable unoptimized Core would take an extra argument for the Show instance. When passing in values to such "foreign" functions it would wrap them up in an interpretive way. This is the hypothetical idea, it seems like it would yield a really trivial way to write a new and interesting interpreter for GHC Haskell without having to re-implement any prim ops, ready to work on regular Haskell code. In my case, I would use this to write an interpreter which: * is not tagless, so we preserve type info * allows top-level names to be redefined * when a function is applied, it checks the type of its arguments Both of these are pretty much necessary for being able to do in-place update of a running program while developing (a la Emacs or Smalltalk), and type tags let us throw a regular Haskell exception of type error, a la deferred type errors. It means in your running program, if you make a mistake or forget to update one part, it doesn't bring the whole program down with an RTS error or a segfault, maybe a handler in a thread (like a server or a video game) throws an exception and the developer just updates their code and tries again. I'd love support for something like this, but I'd rather not have to re-create the world just to add this capability. Because it's really just conceptually regular interpreted GHC Haskell plus type tags and updating, it seems like it should be a small diff. Any input into this? How far away is GHC's current architecture from supporting such a concept? Ciao!

4 7

RE: msys2 64 bit: help help!
by Simon Peyton Jones 28 Jun '16

28 Jun '16

Tamar Thank you! Yes, it's in c:/msys64 Since I wrote more odd things have happened. 1. I just left the machine for 10-15 mins and lo! the shell windows opened up. It just took a loooong time. At this point, starting a new shell no longer took a long time. It all seemed to be working. 2. I then ran pacman -Syuu as instructed on the installation page: https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ The log of what happened is below. There are numerous failures involving Cygwin, which I do not have installed, at least not so far as I know. I do not know if these failures matter. 3. After this step, starting a shell failed altogether with "c:/msys64/mingw64_shell.bat is not recognised as an internal or external command". And sure enough, there is no such file. Presumably it existed in step 1. So perhaps step 2 deleted it? 4. As you mention, I then tried msys2_shell.cmd. It worked -- with a noticeable delay of 5 seconds or so. So I'm less stuck than before but * should I worry about all those install errs * how can I debug what's happening with that long delay * Should I nuke the start menu shortcuts that the msys64 installer so carefully installed in favour of msys2_shell.cmd? Thanks Simon pacman -Syuu :: Synchronising package databases... mingw32 277.4 KiB 501K/s 00:01 [#####################] 100% mingw32.sig 96.0 B 0.00B/s 00:00 [#####################] 100% mingw64 277.0 KiB 481K/s 00:01 [#####################] 100% mingw64.sig 96.0 B 0.00B/s 00:00 [#####################] 100% msys 134.9 KiB 2014K/s 00:00 [#####################] 100% msys.sig 96.0 B 0.00B/s 00:00 [#####################] 100% :: Starting full system upgrade... :: Replace repman-git with msys/pactoys-git? [Y/n] y resolving dependencies... looking for conflicting packages... Packages (41) bash-completion-2.3-1 bsdcpio-3.2.0-1 bsdtar-3.2.0-1 coreutils-8.25-1 crypt-1.3-1 curl-7.49.1-1 file-5.25-1 filesystem-2016.05-3 gcc-libs-5.3.0-3 gettext-0.19.7-3 gmp-6.1.0-2 gnupg-1.4.20-1 grep-2.22-3 gzip-1.7-1 heimdal-libs-1.5.3-9 libarchive-3.2.0-1 libasprintf-0.19.7-3 libassuan-2.4.2-1 libcrypt-1.3-1 libcurl-7.49.1-1 libexpat-2.1.1-1 libgettextpo-0.19.7-3 libgpg-error-1.21-1 libgpgme-1.6.0-1 libintl-0.19.7-3 liblzma-5.2.2-1 libnettle-3.2-1 libopenssl-1.0.2.h-1 libssh2-1.7.0-1 mintty-1~2.2.3-1 mpfr-3.1.4-1 msys2-launcher-git-0.3.29.4028b6c-1 msys2-runtime-2.5.1-1 ncurses-6.0.20160220-1 openssl-1.0.2.h-1 pacman-5.0.1.6403.520736d-1 pactoys-git-r1.e58a7ac-1 rebase-4.4.2-1 repman-git-r23.87bf865-1 [removal] wget-1.17.1-3 xz-5.2.2-1 Total Download Size: 24.85 MiB Total Installed Size: 124.28 MiB Net Upgrade Size: 6.09 MiB :: Proceed with installation? [Y/n] y :: Retrieving packages ... msys2-runtime-2.5.1... 2.2 MiB 912K/s 00:03 [#####################] 100% bash-completion-2.3... 184.1 KiB 4.50M/s 00:00 [#####################] 100% gcc-libs-5.3.0-3-x86_64 783.6 KiB 1818K/s 00:00 [#####################] 100% libintl-0.19.7-3-x86_64 25.6 KiB 3.13M/s 00:00 [#####################] 100% libgettextpo-0.19.7... 110.7 KiB 3.60M/s 00:00 [#####################] 100% libasprintf-0.19.7-... 11.8 KiB 1686K/s 00:00 [#####################] 100% gettext-0.19.7-3-x86_64 1524.1 KiB 1774K/s 00:01 [#####################] 100% liblzma-5.2.2-1-x86_64 76.6 KiB 6.23M/s 00:00 [#####################] 100% gmp-6.1.0-2-x86_64 369.2 KiB 2.03M/s 00:00 [#####################] 100% libnettle-3.2-1-x86_64 101.1 KiB 5.20M/s 00:00 [#####################] 100% coreutils-8.25-1-x86_64 2.2 MiB 1794K/s 00:01 [#####################] 100% ncurses-6.0.2016022... 1147.2 KiB 1833K/s 00:01 [#####################] 100% bsdcpio-3.2.0-1-x86_64 747.1 KiB 2.08M/s 00:00 [#####################] 100% bsdtar-3.2.0-1-x86_64 785.4 KiB 1879K/s 00:00 [#####################] 100% libcrypt-1.3-1-x86_64 13.5 KiB 1692K/s 00:00 [#####################] 100% crypt-1.3-1-x86_64 13.9 KiB 1979K/s 00:00 [#####################] 100% libopenssl-1.0.2.h-... 803.0 KiB 1921K/s 00:00 [#####################] 100% heimdal-libs-1.5.3-... 592.7 KiB 1976K/s 00:00 [#####################] 100% openssl-1.0.2.h-1-x... 1354.4 KiB 1929K/s 00:01 [#####################] 100% gzip-1.7-1-x86_64 97.0 KiB 3.16M/s 00:00 [#####################] 100% libssh2-1.7.0-1-x86_64 170.7 KiB 2.69M/s 00:00 [#####################] 100% libexpat-2.1.1-1-x86_64 56.9 KiB 3.27M/s 00:00 [#####################] 100% libcurl-7.49.1-1-x86_64 191.1 KiB 1855K/s 00:00 [#####################] 100% curl-7.49.1-1-x86_64 608.4 KiB 627K/s 00:01 [#####################] 100% file-5.25-1-x86_64 396.5 KiB 352K/s 00:01 [#####################] 100% filesystem-2016.05-... 36.3 KiB 1297K/s 00:00 [#####################] 100% gnupg-1.4.20-1-x86_64 1026.9 KiB 1927K/s 00:01 [#####################] 100% grep-2.22-3-x86_64 230.3 KiB 2.29M/s 00:00 [#####################] 100% libarchive-3.2.0-1-... 743.4 KiB 2.09M/s 00:00 [#####################] 100% mintty-1~2.2.3-1-x86_64 147.2 KiB 4.64M/s 00:00 [#####################] 100% mpfr-3.1.4-1-x86_64 238.5 KiB 1099K/s 00:00 [#####################] 100% msys2-launcher-git-... 28.5 KiB 2037K/s 00:00 [#####################] 100% xz-5.2.2-1-x86_64 142.5 KiB 3.87M/s 00:00 [#####################] 100% pacman-5.0.1.6403.5... 6.8 MiB 1776K/s 00:04 [#####################] 100% rebase-4.4.2-1-x86_64 236.4 KiB 1487K/s 00:00 [#####################] 100% libgpg-error-1.21-1... 103.8 KiB 3.38M/s 00:00 [#####################] 100% libassuan-2.4.2-1-x... 91.7 KiB 4.71M/s 00:00 [#####################] 100% libgpgme-1.6.0-1-x86_64 175.7 KiB 4.09M/s 00:00 [#####################] 100% wget-1.17.1-3-x86_64 570.7 KiB 2.04M/s 00:00 [#####################] 100% pactoys-git-r1.e58a... 27.7 KiB 3.00M/s 00:00 [#####################] 100% (40/40) checking keys in keyring [#####################] 100% (40/40) checking package integrity [#####################] 100% (40/40) loading package files [#####################] 100% (40/40) checking for file conflicts [#####################] 100% (41/41) checking available disk space [#####################] 100% warning: could not get file information for mingw32/ warning: could not get file information for mingw32/bin/ warning: could not get file information for mingw32/etc/ warning: could not get file information for mingw32/include/ warning: could not get file information for mingw32/lib/ warning: could not get file information for mingw32/share/ warning: could not get file information for mingw64/ warning: could not get file information for mingw64/bin/ warning: could not get file information for mingw64/etc/ warning: could not get file information for mingw64/include/ warning: could not get file information for mingw64/lib/ warning: could not get file information for mingw64/share/ warning: could not get file information for opt/ warning: could not get file information for mingw32.exe warning: could not get file information for mingw32.ini warning: could not get file information for mingw64.exe warning: could not get file information for mingw64.ini warning: could not get file information for msys2.exe warning: could not get file information for msys2.ini warning: could not get file information for autorebasebase1st.bat :: Processing package changes... (1/1) removing repman-git [#####################] 100% ( 1/40) upgrading msys2-runtime [#####################] 100% ( 2/40) upgrading bash-completion [#####################] 100% ( 3/40) upgrading gcc-libs [#####################] 100% 3 [main] pacman (8492) C:\msys64\usr\bin\pacman.exe: *** fatal error - cyg heap base mismatch detected - 0x180326400/0x18033A400. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start->Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. 0 [main] pacman 6424 fork: child -1 - forked process 8492 died unexpectedl y, retry 0, exit code 0xC0000142, errno 11 error: could not fork a new process (Resource temporarily unavailable) ( 4/40) upgrading libintl [#####################] 100% ( 5/40) upgrading libgettextpo [#####################] 100% ( 6/40) upgrading libasprintf [#####################] 100% ( 7/40) upgrading gettext [#####################] 100% 1 [main] pacman (700) C:\msys64\usr\bin\pacman.exe: *** fatal error - cygh eap base mismatch detected - 0x180326400/0x18033A400. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start->Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. 1793360 [main] pacman 6424 fork: child -1 - forked process 700 died unexpectedly , retry 0, exit code 0xC0000142, errno 11 error: could not fork a new process (Resource temporarily unavailable) ( 8/40) upgrading liblzma [#####################] 100% ( 9/40) upgrading gmp [#####################] 100% 1 [main] pacman (3128) C:\msys64\usr\bin\pacman.exe: *** fatal error - cyg heap base mismatch detected - 0x180326400/0x18033A400. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start->Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. 1942064 [main] pacman 6424 fork: child -1 - forked process 3128 died unexpectedl y, retry 0, exit code 0xC0000142, errno 11 error: could not fork  installing pactoys-git [#####################] 100% -----Original Message----- From: Tamar Christina [mailto:tamar@zhox.com] Sent: 27 June 2016 09:19 To: Simon Peyton Jones <simonpj(a)microsoft.com> Cc: ghc-devs(a)haskell.org Subject: Re: msys2 64 bit: help help! Hi Simon, Did you install it to the default location (C:\Msys64) or to a location with spaces in the path? The Msys2 stuff is quite particular about spaces in the path. If that's not the case, then in the install location of msys2 you should find 3 batch files (mingw32.bat, mingw64.bat and msys2_shell.bat) If you only have the msys2_shell.bat use that one instead of mingw64.bat (msys2 in an update will change the shortcuts so I am not sure if the update was done already on your install). Open a command-line window and run that batch file. It should then show you the error without closing the window. alternatively, you can try starting bash in cmd instead of mitty, using "set MSYSTEM=MINGW64 && E:\msys64 E:\msys64\usr\bin\bash --login" replacing the path with your install path. Let me know if these don't work. Kind Regards, Tamar 3 batch files ---- On Mon, 27 Jun 2016 10:01:28 +0200 Simon Peyton Jones wrote ---- > Friends, esp Tamar, > > I am in happy possession of a new Surface Book, running Windows 10, which is delightful – except that I can’t make the msys64 installation work, which is crucial for GHC. Can any of you help? > > · I install it from here: https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fsourceforg…, which seems to be the canonical place. The actual 64-bit exe seems to be msys2-x86_64-20160205.exe. > · Installation goes fine > · But when I launch the “MinGW-w54 Win64 shell” from the Start menu, the screen flashes as if it is briefly putting up a window, but then the window disappears. > · Each time I do this the task manager shows that there is another running ‘mintty.exe’. But it has no visible window > > Does anyone have any idea what I can do or how I can investigate? I can’t do any GHC development without this! > > Thanks > > Simon > > > >

5 9

RE: msys2 64 bit: help help!
by Andrey Mokhov 27 Jun '16

27 Jun '16

Hi Simon, > 3. After this step, starting a shell failed altogether with "c:/msys64/mingw64_shell.bat is > not recognised as an internal or external command". And sure enough, there is no such file. > Presumably it existed in step 1. So perhaps step 2 deleted it? > [...] > 4. As you mention, I then tried msys2_shell.cmd. It worked -- with a noticeable delay of 5 > seconds or so. I've also just got a new Win10 laptop and had the same issue with missing mingw64_shell.bat during msys2 install. I solved it by creating mingw64.bat with the following contents: msys2_shell.cmd -mingw64 -mintty I deleted all old shortcuts and use this script instead. Everything seems to work fine -- can build GHC. Cheers, Andrey

2 1

msys2 64 bit: help help!
by Simon Peyton Jones 27 Jun '16

27 Jun '16

Friends, esp Tamar, I am in happy possession of a new Surface Book, running Windows 10, which is delightful - except that I can't make the msys64 installation work, which is crucial for GHC. Can any of you help? * I install it from here: https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/, which seems to be the canonical place. The actual 64-bit exe seems to be msys2-x86_64-20160205.exe. * Installation goes fine * But when I launch the "MinGW-w54 Win64 shell" from the Start menu, the screen flashes as if it is briefly putting up a window, but then the window disappears. * Each time I do this the task manager shows that there is another running 'mintty.exe'. But it has no visible window Does anyone have any idea what I can do or how I can investigate? I can't do any GHC development without this! Thanks Simon

3 2

RE: [Diffusion] [Build Failed] rGHCbb84ee44e30e: Improve pretty-printing of Avail
by Simon Peyton Jones 27 Jun '16

27 Jun '16

These failures are odd. One is this change in T8761 which I'm sure is not my fault. I saw that simonmar did some hFlush thing -- could that be it? Simon +++ ./T8761.run/T8761.comp.stderr.normalised 2016-06-24 15:00:22.975083533 +0100 @@ -1,3 +1,7 @@ +pattern Q1 x1_0 x2_1 x3_2 <- ((x1_0, x2_1), [x3_2], _, _) +pattern x1_0 Q2 x2_1 = ((x1_0, x2_1)) +pattern Q3 {qx3, qy3, qz3} <- ((qx3, qy3), [qz3]) where + Q3 qx3 qy3 qz3 = ((qx3, qy3), [qz3]) T8761.hs:(16,1)-(39,13): Splicing declarations do { [qx1, qy1, qz1] <- mapM (/ i -> newName $ "x" ++ show i) [1, 2, 3]; @@ -119,10 +123,6 @@ pattern Pup x <- MkUnivProv x pattern Puep :: forall a. forall b. Show b => a -> b -> (ExProv, a) pattern Puep x y <- (MkExProv y, x) -pattern Q1 x1_0 x2_1 x3_2 <- ((x1_0, x2_1), [x3_2], _, _) -pattern x1_0 Q2 x2_1 = ((x1_0, x2_1)) -pattern Q3 {qx3, qy3, qz3} <- ((qx3, qy3), [qz3]) where - Q3 qx3 qy3 qz3 = ((qx3, qy3), [qz3]) pattern T8761.P :: GHC.Types.Bool pattern T8761.Pe :: () => forall (a0_0 :: *) . a0_0 -> T8761.Ex pattern T8761.Pu :: forall (a0_0 :: *) . a0_0 -> a0_0 | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 24 June 2016 14:50 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: [Diffusion] [Build Failed] rGHCbb84ee44e30e: Improve pretty- | printing of Avail | | Harbormaster failed to build B10226: rGHCbb84ee44e30e: Improve pretty- | printing of Avail! | | BRANCHES | master, wip/rae | | USERS | simonpj (Author) | | COMMIT | https://phabricator.haskell.org/rGHCbb84ee44e30e | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, Harbormaster

2 1

RE: [commit: ghc] master: Accept new (lower) allocations for T7257 (15641b0)
by Simon Peyton Jones 27 Jun '16

27 Jun '16

Does anyone know what made T7257 better? Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 22 June 2016 22:08 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Accept new (lower) allocations for T7257 | (15641b0) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fghc.hask | ell.org%2ftrac%2fghc%2fchangeset%2f15641b07f1d3ccb5f35b4f31539ecceb5fb38 | c17%2fghc&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c32fafc88b758 | 43148b2a08d39ae1ea3f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=eLrMob | XyWHA691jI3t4pf0CbGybfrVqptmkpTDdtDI8%3d | | >--------------------------------------------------------------- | | commit 15641b07f1d3ccb5f35b4f31539ecceb5fb38c17 | Author: Simon Marlow <marlowsd(a)gmail.com> | Date: Wed Jun 22 20:54:59 2016 +0100 | | Accept new (lower) allocations for T7257 | | | >--------------------------------------------------------------- | | 15641b07f1d3ccb5f35b4f31539ecceb5fb38c17 | testsuite/tests/perf/should_run/all.T | 3 ++- | 1 file changed, 2 insertions(+), 1 deletion(-) | | diff --git a/testsuite/tests/perf/should_run/all.T | b/testsuite/tests/perf/should_run/all.T | index caf4eff..3cb6f8e 100644 | --- a/testsuite/tests/perf/should_run/all.T | +++ b/testsuite/tests/perf/should_run/all.T | @@ -276,9 +276,10 @@ test('T7257', | [(wordsize(32), 989850664, 10), | # expected value: 1246287228 (i386/Linux) | # 2016-04-06: 989850664 (i386/Linux) no idea | what happened | - (wordsize(64), 1654893248, 5)]), | + (wordsize(64), 1414893248, 5)]), | # 2012-09-21: 1774893760 (amd64/Linux) | # 2015-11-03: 1654893248 (amd64/Linux) | + # 2016-06-22: 1414893248 (amd64/Linux, sizeExpr | fix) | stats_num_field('peak_megabytes_allocated', | [(wordsize(32), 217, 5), | # 2012-10-08: 217 (x86/Linux) | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.has | kell.org%2fcgi-bin%2fmailman%2flistinfo%2fghc- | commits&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c32fafc88b75843 | 148b2a08d39ae1ea3f%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=RftvNpBH | H7bw53EdhgnsdV%2f6M2LNgFVB1t7gCwOTT7A%3d

3 2

CMM-to-ASM: Register allocation wierdness
by Harendra Kumar 26 Jun '16

26 Jun '16

Hi, I am implementing unicode normalization in Haskell. I challenged myself to match the performance with the best C/C++ implementation, the best being the ICU library. I am almost there, beating it in one of the benchmarks and within 30% for others. I am out of all application level tricks that I could think of and now need help from the compiler. I started with a bare minimum loop and adding functionality incrementally watching where the performance trips. At one point I saw that adding just one 'if' condition reduced the performance by half. I looked at what's going on at the assembly level. Here is a github gist of the assembly instructions executed in the fast path of the loop, corresponding cmm snippets and also the full cmm corresponding to the loop: https://gist.github.com/harendra-kumar/7d34c6745f604a15a872768e57cd2447 I have annotated the assembly code with labels matching the corresponding CMM. With the addition of another "if" condition the loop which was pretty simple till now suddenly got bloated with a lot of register reassignments. Here is a snippet of the register movements added: # _n4se: # swap r14 <-> r11 => 0x408d6b: mov %r11,0x98(%rsp) => 0x408d73: mov %r14,%r11 => 0x408d76: mov 0x98(%rsp),%r14 # reassignments # rbx -> r10 -> r9 -> r8 -> rdi -> rsi -> rdx -> rcx -> rbx => 0x408d7e: mov %rbx,0x90(%rsp) => 0x408d86: mov %rcx,%rbx => 0x408d89: mov %rdx,%rcx => 0x408d8c: mov %rsi,%rdx => 0x408d8f: mov %rdi,%rsi => 0x408d92: mov %r8,%rdi => 0x408d95: mov %r9,%r8 => 0x408d98: mov %r10,%r9 => 0x408d9b: mov 0x90(%rsp),%r10 . . . loop logic here which uses only %rax, %r10 and %r9 . . . . # _n4s8: # shuffle back to original assignments => 0x4090dc: mov %r14,%r11 => 0x4090df: mov %r9,%r10 => 0x4090e2: mov %r8,%r9 => 0x4090e5: mov %rdi,%r8 => 0x4090e8: mov %rsi,%rdi => 0x4090eb: mov %rdx,%rsi => 0x4090ee: mov %rcx,%rdx => 0x4090f1: mov %rbx,%rcx => 0x4090f4: mov %rax,%rbx => 0x4090f7: mov 0x88(%rsp),%rax => 0x4090ff: jmpq 0x408d2a The registers seem to be getting reassigned here, data flowing from one to the next. In this particular path a lot of these register movements seem unnecessary and are only undone at the end without being used. Maybe this is because these are reusable blocks and the movement is necessary when used in some other path? Can this be avoided? Or at least avoided in a certain fast path somehow by hinting the compiler? Any pointers to the GHC code will be appreciated. I am not yet much familiar with the GHC code but can dig deeper pretty quickly. But before that I hope someone knowledgeable in this area can shed some light on this at a conceptual level or if at all it can be improved. I can provide more details and experiment more if needed. Thanks, Harendra

5 13

T8761 failing for ext-interp
by Richard Eisenberg 26 Jun '16

26 Jun '16

Hi Simon, Phab tells us that T8761 is failing for the ext-interp way, as of d2006d050e7a9111c0c448d6262f8994ef5761b7 (Run all TH tests with -fexternal-interpreter (#12219)). See https://phabricator.haskell.org/B10229 Thanks, Richard

3 6