From simonpj at microsoft.com  Wed Mar  1 00:07:23 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 1 Mar 2017 00:07:23 +0000
Subject: Windows build broken
Message-ID: <DM2PR21MB00282E845B481D4FB5BFCCD9AD290@DM2PR21MB0028.namprd21.prod.outlook.com>

Windows build is broken again.  Might someone fix?
Simon


"inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_p\" -optc-DWINVER=0x06000100 -static -prof -eventlog  -O0 -H64m -Wall -fllvm-fill-undef-with-garbage    -Werror -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint      -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen           -O2    -Wnoncanonical-monad-instances  -c rts/Sparks.c -o rts/dist/build/Sparks.p_o

rts\Profiling.c: In function 'reportCCSProfiling':



rts\Profiling.c:704:9: error:

     error: implicit declaration of function 'writeCCSReportJson' [-Werror=implicit-function-declaration]

             writeCCSReportJson(prof_file, stack, totals);

             ^~~~~~~~~~~~~~~~~~

    |

704 |         writeCCSReportJson(prof_file, stack, totals);

    |         ^



rts\Profiling.c:704:9: error:

     error: nested extern declaration of 'writeCCSReportJson' [-Werror=nested-externs]

    |

704 |         writeCCSReportJson(prof_file, stack, totals);

    |         ^

cc1.exe: all warnings being treated as errors

`gcc.exe' failed in phase `C Compiler'. (Exit code: 1)

make[1]: *** [rts/ghc.mk:255: rts/dist/build/Profiling.p_o] Error 1

make[1]: *** Waiting for unfinished jobs....

make: *** [Makefile:127: all] Error 2

/c/code/HEAD$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170301/88221f41/attachment.html>

From david at well-typed.com  Wed Mar  1 00:12:05 2017
From: david at well-typed.com (David Feuer)
Date: Tue, 28 Feb 2017 19:12:05 -0500
Subject: Windows build broken
Message-ID: <umun01ssei7ugch146d18uei.1488327125295@email.android.com>


I can't fix that (no windows) but I just broke all the builds with a -Werror mistake and I can fix that one...

David FeuerWell-Typed, LLP
-------- Original message --------From: Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> Date: 2/28/17  7:07 PM  (GMT-05:00) To: ghc-devs at haskell.org Subject: Windows build broken 


Windows build is broken again.  Might someone fix?
Simon
 
"inplace/bin/ghc-stage1.exe" -optc-fno-stack-protector -optc-Wall -optc-Werror -optc-Wall -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith
 -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes -optc-Iincludes/dist -optc-Iincludes/dist-derivedconstants/header -optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build -optc-DCOMPILING_RTS -optc-fno-strict-aliasing
 -optc-fno-common -optc-Irts/dist/build/./autogen -optc-Wno-error=inline -optc-O2 -optc-fomit-frame-pointer -optc-g -optc-DRtsWay=\"rts_p\" -optc-DWINVER=0x06000100 -static -prof -eventlog  -O0 -H64m -Wall -fllvm-fill-undef-with-garbage    -Werror -Iincludes
 -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint      -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen          
 -O2    -Wnoncanonical-monad-instances  -c rts/Sparks.c -o rts/dist/build/Sparks.p_o
rts\Profiling.c: In function 'reportCCSProfiling':
 
rts\Profiling.c:704:9: error:
     error: implicit declaration of function 'writeCCSReportJson' [-Werror=implicit-function-declaration]
             writeCCSReportJson(prof_file, stack, totals);
             ^~~~~~~~~~~~~~~~~~
    |
704 |         writeCCSReportJson(prof_file, stack, totals);
    |         ^
 
rts\Profiling.c:704:9: error:
     error: nested extern declaration of 'writeCCSReportJson' [-Werror=nested-externs]
    |
704 |         writeCCSReportJson(prof_file, stack, totals);
    |         ^
cc1.exe: all warnings being treated as errors
`gcc.exe' failed in phase `C Compiler'. (Exit code: 1)
make[1]: *** [rts/ghc.mk:255: rts/dist/build/Profiling.p_o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:127: all] Error 2
/c/code/HEAD$

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170228/b269533a/attachment.html>

From simonpj at microsoft.com  Wed Mar  1 08:17:05 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 1 Mar 2017 08:17:05 +0000
Subject: collectBindersPushingCo
Message-ID: <DM2PR21MB0028DD82F06038164F27AC2FAD290@DM2PR21MB0028.namprd21.prod.outlook.com>

David
Thanks for moving my early-inline patch series to HEAD.
You'll remember that I pushed this patch (below) to spj-early-inline2
Can you be sure to cherry-pick this one too?  It's important and I don't see it in HEAD yet.  I'm surprised that there isn't a validate failure (T9505 if memory serves - see attached).
Simon


commit 002192aa8df463ae945e8a94147cfc1d848f43a5

Author: Simon Peyton Jones <simonpj at microsoft.com>

Date:   Fri Feb 24 16:55:36 2017 +0000



    Fix a nasty bug in CoreSubst.collectBindersPushingCo



    The bug wsa in the use of (mkNthCo 0) to get the argument

    part of a function coercion.  Not so! Now (->) takes four

    arguments so that 0 should have been 2.



    Enough with magic numbers. I defined decomposeFunCo, and used

    it throughout.  Much nicer now; and correct.



    The nete effect, incidentally, was that T9509 was failing to

    specialise.  (And that was the initial reason for introducing

    collectBindersPushingCo in the first place.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170301/cdf1a6cf/attachment-0001.html>
-------------- next part --------------
An embedded message was scrubbed...
From: Simon Peyton Jones <simonpj at microsoft.com>
Subject: RE: Progress on early inline
Date: Fri, 24 Feb 2017 16:59:25 +0000
Size: 18511
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170301/cdf1a6cf/attachment-0001.mht>

From david at well-typed.com  Wed Mar  1 13:49:19 2017
From: david at well-typed.com (David Feuer)
Date: Wed, 01 Mar 2017 08:49:19 -0500
Subject: collectBindersPushingCo
In-Reply-To: <DM2PR21MB0028DD82F06038164F27AC2FAD290@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <DM2PR21MB0028DD82F06038164F27AC2FAD290@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <2024218.flRWX56S0U@squirrel>

On Wednesday, March 1, 2017 8:17:05 AM EST Simon Peyton Jones via ghc-devs 
wrote:
> David
> Thanks for moving my early-inline patch series to HEAD.
> You'll remember that I pushed this patch (below) to spj-early-inline2
> Can you be sure to cherry-pick this one too?  It's important and I don't see
> it in HEAD yet.  I'm surprised that there isn't a validate failure (T9505
> if memory serves - see attached). Simon

It looks to me like these changes were included in one of Ben's patches. As 
far as I can tell, this is as you intend in HEAD.

David

From simonpj at microsoft.com  Wed Mar  1 21:40:34 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 1 Mar 2017 21:40:34 +0000
Subject: collectBindersPushingCo
In-Reply-To: <2024218.flRWX56S0U@squirrel>
References: <DM2PR21MB0028DD82F06038164F27AC2FAD290@DM2PR21MB0028.namprd21.prod.outlook.com>
 <2024218.flRWX56S0U@squirrel>
Message-ID: <DM2PR21MB00281C92066AABEA3251E417AD290@DM2PR21MB0028.namprd21.prod.outlook.com>

Ah yes.  He combined it into

commit 1990bb0df51250519b555ec271c693d289dd9802
Author: Simon Peyton Jones <simonpj at microsoft.com>
Date:   Tue Feb 28 12:11:33 2017 -0500

    Make Specialise work with casts

Thanks

Simon

| -----Original Message-----
| From: David Feuer [mailto:david at well-typed.com]
| Sent: 01 March 2017 13:49
| To: ghc-devs at haskell.org; Simon Peyton Jones <simonpj at microsoft.com>
| Cc: David Feuer <david.feuer at gmail.com>; ben at well-typed.com
| Subject: Re: collectBindersPushingCo
| 
| On Wednesday, March 1, 2017 8:17:05 AM EST Simon Peyton Jones via ghc-
| devs
| wrote:
| > David
| > Thanks for moving my early-inline patch series to HEAD.
| > You'll remember that I pushed this patch (below) to spj-early-inline2
| > Can you be sure to cherry-pick this one too?  It's important and I
| > don't see it in HEAD yet.  I'm surprised that there isn't a validate
| > failure (T9505 if memory serves - see attached). Simon
| 
| It looks to me like these changes were included in one of Ben's patches.
| As far as I can tell, this is as you intend in HEAD.
| 
| David

From david.feuer at gmail.com  Fri Mar  3 20:31:46 2017
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 3 Mar 2017 15:31:46 -0500
Subject: Additional catch notes
In-Reply-To: <CAMgWh9s6zZRd8LAGHvnr-C=2MuZTOxyLqBUom9bbKhg9RF2_-A@mail.gmail.com>
References: <CAMgWh9vgOfutxt0JTA3PcNGNDv8dzrh0v0X22JYHe1ZPUhEE9A@mail.gmail.com>
 <CAMgWh9uaUzYD-wmr57csd5UjXJ9rqHR66ToWTTBKknLvZXrmmg@mail.gmail.com>
 <CAMgWh9spTL0=Cr7=bXnLQvhzpkK6z3AnbeigYF4zE5CVbqSjAA@mail.gmail.com>
 <CAMgWh9t2F_3PMp9RgJYoCFBvjM2-kYQYCcFdwxL1qxFmCXh_PA@mail.gmail.com>
 <CAMgWh9vq8itaoaZw1RiBK6CqPqk7O+SZYFRF7wXePDzWR-Oykg@mail.gmail.com>
 <CAMgWh9u0Exk-UGYYOqnCb9cef8CRKUkVNSmfJOnpv6SiEOe=WQ@mail.gmail.com>
 <CAMgWh9um45gggqRqUrpBgKYeq7JedygjAMEYOm8UAANpUMEXeA@mail.gmail.com>
 <CAMgWh9tMjW0hsTu6itSzZo_B2zXPwa0vCBdZuWDRs-VDJu=Taw@mail.gmail.com>
 <CAMgWh9v3DWN_wXv6uJYBk8iViVxhy2HTS_uEAY99xdM=LSvWEA@mail.gmail.com>
 <CAMgWh9t6z97dLxru6fZu9qoGFg96-ZfUpFSoONNSTQM4M6y2jA@mail.gmail.com>
 <CAMgWh9vsLAJvojeN4v0HkhjAuGFYHpCPKZNsNwGBpHPp=Ji5Qw@mail.gmail.com>
 <CAMgWh9u67VRmnAJ8HaLRyvzg8n==mmczCXr+EyEi58YTY84QEw@mail.gmail.com>
 <CAMgWh9spZQn1oeep9a38vQ=C3dFdxrHc2_vc5KiCpffYrWtsKw@mail.gmail.com>
 <CAMgWh9uwZcRQOj0ERf2ZrKAPK4XbnjX2ZFVuLta6RXD3deQH+Q@mail.gmail.com>
 <CAMgWh9s+UOGV_Q+Lw=Q_9envvXGuPJapETm+Fm3eRuHZuiyHjA@mail.gmail.com>
 <CAMgWh9s6zZRd8LAGHvnr-C=2MuZTOxyLqBUom9bbKhg9RF2_-A@mail.gmail.com>
Message-ID: <CAMgWh9vYi-nGiebMsf2odRskmHx9dRZ7Drd48wibYxW39Rz4Dw@mail.gmail.com>

I dug a little further into what you tried to do with catch and where I
think it went wrong. You can see my thoughts in the notes I added in D3263.
It could even be possible to fix the problem for real by changing the
DmdRes domain again. Originally, we broke it up into Diverges and Dunno.
You added an additional ThrowsExn to mean "diverges or throws an
exception". But I think a critical point in the domain, for this analysis,
is "definitely does not throw an exception". If we have

catch# m f s

then we can speculatively evaluate/unbox only those expressions in (m s)
that definitely don't throw exceptions (whether they succeed or diverge).

One other thought: it might be worth considering a catchIO# primitive. This
would catch exceptions thrown by raiseIO# but *not* by raise#. This could
be made *much* stricter, I believe, if give raiseIO# a special place in the
result domain.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170303/22151e07/attachment.html>

From mail at joachim-breitner.de  Sat Mar  4 19:56:26 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 04 Mar 2017 20:56:26 +0100
Subject: Travis again over time
Message-ID: <1488657386.11972.3.camel@joachim-breitner.de>

Hi,

I just noticed that travis again fails to build master, and did so for
four days.

The build logs only get sent to the committer, so if the first person
breaking the build does not react, then all following commiters (who
likely did obviously benign changes) will likely ignore any failures,
(even if they break some of the test cases) and we have a broken-window 
effect. I wonder if we should configure travis to send build error
messags to, for example, ghc-commits?


Anyways, build time has increased and reached the (recently raised)
time limit of 70 minutes. I fail to identify an obviously offending
commit. Last working commit (which, by sheer luck, passed the time
limit) was
https://github.com/ghc/ghc/commit/fc6c222b90e68fed74a6bee6f087f47bf31f21c6

It looks that much of the time increase is due to enabling split
sections by default:
https://travis-ci.org/ghc/ghc/builds/198293519
I’ll see if that helps.

Greetings,
Joachim


-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170304/91c7e221/attachment.sig>

From simonpj at microsoft.com  Sat Mar  4 21:01:24 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Sat, 4 Mar 2017 21:01:24 +0000
Subject: Windows build broken again
Message-ID: <DM2PR21MB00284992F97EE7AD5451402DAD2A0@DM2PR21MB0028.namprd21.prod.outlook.com>

The Windows build is broken again.  Here's the tail of the log



It would be good if we could stop this happening



Simon

== End post-build package check

make: Entering directory '/c/code/HEAD/testsuite/tests'

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

"/c/code/HEAD/inplace/bin/ghc-stage2.exe" --make -o ../mk/ghc-config ../mk/ghc-config.hs

[1 of 1] Compiling Main             ( ..\mk\ghc-config.hs, ..\mk\ghc-config.o )

Linking ../mk/ghc-config.exe ...

../mk/ghc-config "/c/code/HEAD/inplace/bin/ghc-stage2.exe" >"../mk/ghcconfig_c_code_HEAD_inplace_bin_ghc-stage2.exe.mk"; if [ $? != 0 ]; then rm -f "../mk/ghcconfig_c_code_HEAD_inplace_bin_ghc-stage2.exe.mk"; exit 1; fi

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

# See Note [validate and testsuite speed] in toplevel Makefile.

make SPEED=2

make[1]: Entering directory '/c/code/HEAD/testsuite/tests'

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

Looks like you don't have timeout, building it first...

make -C ../timeout all

make[2]: Entering directory '/c/code/HEAD/testsuite/timeout'

rm -f -f TimeMe.o TimeMe.hi TimeMe TimeMe.exe

python3 calibrate '' > calibrate.out

rm -rf install-inplace

'/c/code/HEAD/inplace/bin/ghc-stage2.exe' --make Setup

[1 of 1] Compiling Main             ( Setup.hs, Setup.o )

Linking Setup.exe ...

./Setup configure --with-compiler='/c/code/HEAD/inplace/bin/ghc-stage2.exe' \

                  --with-hc-pkg='/c/code/HEAD/inplace/bin/ghc-pkg.exe' \

                  --with-hsc2hs='/c/code/HEAD/inplace/bin/hsc2hs.exe' \

                   \

                  --ghc-option=-threaded --prefix='/c/code/HEAD/testsuite/timeout/install-inplace'

Configuring timeout-1...

./Setup build

Preprocessing executable 'timeout' for timeout-1..

Building executable 'timeout' for timeout-1..

[1 of 2] Compiling WinCBindings     ( dist\build\timeout\timeout-tmp\WinCBindings.hs, dist\build\timeout\timeout-tmp\WinCBindings.o )

[2 of 2] Compiling Main             ( timeout.hs, dist\build\timeout\timeout-tmp\Main.o )

Linking dist\build\timeout\timeout.exe ...

./Setup install

Installing executable timeout in C:/code/HEAD/testsuite/timeout/install-inplace\bin

Warning: The directory C:/code/HEAD/testsuite/timeout/install-inplace\bin is

not in the system search path.

make[2]: Leaving directory '/c/code/HEAD/testsuite/timeout'

PYTHON="python3" "python3" ../driver/runtests.py  -e ghc_compiler_always_flags="'-dcore-lint -dcmm-lint -no-user-package-db -rtsopts  -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output'" -e config.compiler_debugged=False -e ghc_with_native_codegen=1 -e config.have_vanilla=True -e config.have_dynamic=False -e config.have_profiling=False -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=0 -e config.have_interp=True -e config.unregisterised=False -e config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=True -e darwin=False -e config.in_tree_compiler=True --threads=5 -e config.cleanup=True -e config.local=False --rootdir=. --configfile=../config/ghc -e 'config.confdir="../config"' -e 'config.platform="x86_64-unknown-mingw32"' -e 'config.os="mingw32"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=".exe"' -e 'config.top="/c/code/HEAD/testsuite"' --config 'compiler="/c/code/HEAD/inplace/bin/ghc-stage2.exe"' --config 'ghc_pkg="/c/code/HEAD/inplace/bin/ghc-pkg.exe"' --config 'haddock="/c/code/HEAD/inplace/bin/haddock.exe"' --config 'hp2ps="/c/code/HEAD/inplace/bin/hp2ps.exe"' --config 'hpc="/c/code/HEAD/inplace/bin/hpc.exe"' --config 'gs="gs"' --config 'timeout_prog="../timeout/install-inplace/bin/timeout.exe"' -e "config.stage=2" --summary-file "../../testsuite_summary.txt" --no-print-summary 1   --rootdir=../../libraries/Win32/tests  --rootdir=../../libraries/array/tests  --rootdir=../../libraries/base/tests  --rootdir=../../libraries/binary/tests  --rootdir=../../libraries/bytestring/tests  --rootdir=../../libraries/containers/tests  --rootdir=../../libraries/deepseq/tests  --rootdir=../../libraries/directory/tests  --rootdir=../../libraries/filepath/tests  --rootdir=../../libraries/ghc-compact/tests  --rootdir=../../libraries/ghc-prim/tests  --rootdir=../../libraries/haskeline/tests  --rootdir=../../libraries/hpc/tests  --rootdir=../../libraries/pretty/tests  --rootdir=../../libraries/process/tests  --rootdir=../../libraries/template-haskell/tests \

      \

      \

      \

      \

      \

      -e config.speed="2" \



Traceback (most recent call last):

  File "../driver/runtests.py", line 189, in <module>

    pkginfo = str(getStdout([config.ghc_pkg, 'dump']))

  File "/c/code/HEAD/testsuite/driver/testutil.py", line 25, in getStdout

    raise Exception("stderr from command: " + str(cmd_and_args))

Exception: stderr from command: ['"/c/code/HEAD/inplace/bin/ghc-pkg.exe"', 'dump']

make[1]: *** [../mk/test.mk:299: test] Error 1

make[1]: Leaving directory '/c/code/HEAD/testsuite/tests'

make: *** [../mk/test.mk:315: fasttest] Error 2

make: Leaving directory '/c/code/HEAD/testsuite/tests'

make: Entering directory '/c/code/HEAD/testsuite/tests/stage1'

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

../../mk/ghc-config "/c/code/HEAD/inplace/bin/ghc-stage1.exe" >"../../mk/ghcconfig_c_code_HEAD_inplace_bin_ghc-stage1.exe.mk"; if [ $? != 0 ]; then rm -f "../../mk/ghcconfig_c_code_HEAD_inplace_bin_ghc-stage1.exe.mk"; exit 1; fi

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

# See Note [validate and testsuite speed] in toplevel Makefile.

make SPEED=2

make[1]: Entering directory '/c/code/HEAD/testsuite/tests/stage1'

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

PYTHON="python3" "python3" ../../driver/runtests.py  -e ghc_compiler_always_flags="'-dcore-lint -dcmm-lint -no-user-package-db -rtsopts  -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output'" -e config.compiler_debugged=True -e ghc_with_native_codegen=1 -e config.have_vanilla=True -e config.have_dynamic=False -e config.have_profiling=False -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=0 -e config.have_interp=False -e config.unregisterised=False -e config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=True -e darwin=False -e config.in_tree_compiler=True --threads=5 -e config.cleanup=True -e config.local=False --rootdir=. --configfile=../../config/ghc -e 'config.confdir="../../config"' -e 'config.platform="x86_64-unknown-mingw32"' -e 'config.os="mingw32"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=".exe"' -e 'config.top="/c/code/HEAD/testsuite"' --config 'compiler="/c/code/HEAD/inplace/bin/ghc-stage1.exe"' --config 'ghc_pkg="/c/code/HEAD/inplace/bin/ghc-pkg.exe"' --config 'haddock="/c/code/HEAD/inplace/bin/haddock.exe"' --config 'hp2ps="/c/code/HEAD/inplace/bin/hp2ps.exe"' --config 'hpc="/c/code/HEAD/inplace/bin/hpc.exe"' --config 'gs="gs"' --config 'timeout_prog="../../timeout/install-inplace/bin/timeout.exe"' -e "config.stage=1" --summary-file "../../../testsuite_summary_stage1.txt" --no-print-summary 1  \

      \

      \

      \

      \

      \

      -e config.speed="2" \



Traceback (most recent call last):

  File "../../driver/runtests.py", line 189, in <module>

    pkginfo = str(getStdout([config.ghc_pkg, 'dump']))

  File "/c/code/HEAD/testsuite/driver/testutil.py", line 25, in getStdout

    raise Exception("stderr from command: " + str(cmd_and_args))

Exception: stderr from command: ['"/c/code/HEAD/inplace/bin/ghc-pkg.exe"', 'dump']

make[1]: *** [../../mk/test.mk:299: test] Error 1

make[1]: Leaving directory '/c/code/HEAD/testsuite/tests/stage1'

make: *** [../../mk/test.mk:315: fasttest] Error 2

make: Leaving directory '/c/code/HEAD/testsuite/tests/stage1'



==== STAGE 1 TESTS ====

cat: testsuite_summary_stage1.txt: No such file or directory

/c/code/HEAD$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170304/1331eff0/attachment-0001.html>

From rae at cs.brynmawr.edu  Sun Mar  5 15:00:57 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sun, 5 Mar 2017 08:00:57 -0700
Subject: Travis again over time
In-Reply-To: <1488657386.11972.3.camel@joachim-breitner.de>
References: <1488657386.11972.3.camel@joachim-breitner.de>
Message-ID: <7CD5F48A-2533-4B71-905F-887A388D65E0@cs.brynmawr.edu>


> On Mar 4, 2017, at 12:56 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> I wonder if we should configure travis to send build error
> messags to, for example, ghc-commits?

+1 to public shaming. Where we understand that there is no shame is making mistakes.

Richard

From mail at joachim-breitner.de  Sun Mar  5 15:37:00 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 05 Mar 2017 16:37:00 +0100
Subject: Travis again over time
In-Reply-To: <1488657386.11972.3.camel@joachim-breitner.de>
References: <1488657386.11972.3.camel@joachim-breitner.de>
Message-ID: <1488728220.8321.0.camel@joachim-breitner.de>

Hi,

Am Samstag, den 04.03.2017, 20:56 +0100 schrieb Joachim Breitner:
> It looks that much of the time increase is due to enabling split
> sections by default:
> https://travis-ci.org/ghc/ghc/builds/198293519
> I’ll see if that helps.

nope, even with
echo 'SplitSections      = NO'        >> mk/validate.mk
we run over the time limit.

Not sure what best to do next.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170305/7ed1cd85/attachment.sig>

From simonpj at microsoft.com  Mon Mar  6 15:45:49 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 6 Mar 2017 15:45:49 +0000
Subject: Better perf
Message-ID: <DM2PR21MB00287EB1E6B98C9A1550C897AD2C0@DM2PR21MB0028.namprd21.prod.outlook.com>

I've just committed this patch sequence

fb9ae288088a3eabc4e1bb4e86fa473a3881d2e2 Make FloatOut/SetLevels idemoptent on bottoming functions

995ab74b3c55fe3a0299bd94b49e948c942e76d6 Comments only

1163f4f2fe9aabd722c963497c67c5f8c71ef71b Tiny refactor

9b2c73ea8082199245bfa6a28390b70b38f87fd1 Make TH_Roles2 less fragile

9304df5230a7a29d3e992916d133e462b854e55f Fix CSE (again) on literal strings
In my final validate run (after updating to HEAD) I saw

Unexpected stat failures:

   perf/compiler/T13035.run    T13035 [stat too good] (normal)

-6.4% alloc



   perf/compiler/T12425.run    T12425 [stat too good] (optasm)

-6.6% alloc



   perf/compiler/T9675.run     T9675 [stat too good] (optasm)

-10.4% alloc



   perf/compiler/T1969.run     T1969 [stat too good] (normal)

-21% peak megabytes



   perf/space_leaks/T4029.run  T4029 [stat too good] (ghci)

-14% peak megabytes
This is good.  I did not see these in earlier validations (perhaps I did not rebuild the libraries sufficiently), so I have left them.  If Harbormaster agrees that perf has improved, could someone re-centre the numbers?  Ideally say which patch is responsible.
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170306/a04a1e89/attachment.html>

From simonpj at microsoft.com  Mon Mar  6 23:11:43 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 6 Mar 2017 23:11:43 +0000
Subject: Windows build broken again
In-Reply-To: <DM2PR21MB00284992F97EE7AD5451402DAD2A0@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <DM2PR21MB00284992F97EE7AD5451402DAD2A0@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <DM2PR21MB0028952D062DE1924F7EADBCAD2C0@DM2PR21MB0028.namprd21.prod.outlook.com>

Windows build still broken.  Please please could someone fix?
It's something to do with the testsuite Python script
Thanks
Simo[n

From: Simon Peyton Jones
Sent: 04 March 2017 21:01
To: ghc-devs at haskell.org
Subject: Windows build broken again

The Windows build is broken again.  Here's the tail of the log

It would be good if we could stop this happening

Simon

== End post-build package check

make: Entering directory '/c/code/HEAD/testsuite/tests'

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

"/c/code/HEAD/inplace/bin/ghc-stage2.exe" --make -o ../mk/ghc-config ../mk/ghc-config.hs

[1 of 1] Compiling Main             ( ..\mk\ghc-config.hs, ..\mk\ghc-config.o )

Linking ../mk/ghc-config.exe ...

../mk/ghc-config "/c/code/HEAD/inplace/bin/ghc-stage2.exe" >"../mk/ghcconfig_c_code_HEAD_inplace_bin_ghc-stage2.exe.mk"; if [ $? != 0 ]; then rm -f "../mk/ghcconfig_c_code_HEAD_inplace_bin_ghc-stage2.exe.mk"; exit 1; fi

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

# See Note [validate and testsuite speed] in toplevel Makefile.

make SPEED=2

make[1]: Entering directory '/c/code/HEAD/testsuite/tests'

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

Looks like you don't have timeout, building it first...

make -C ../timeout all

make[2]: Entering directory '/c/code/HEAD/testsuite/timeout'

rm -f -f TimeMe.o TimeMe.hi TimeMe TimeMe.exe

python3 calibrate '' > calibrate.out

rm -rf install-inplace

'/c/code/HEAD/inplace/bin/ghc-stage2.exe' --make Setup

[1 of 1] Compiling Main             ( Setup.hs, Setup.o )

Linking Setup.exe ...

./Setup configure --with-compiler='/c/code/HEAD/inplace/bin/ghc-stage2.exe' \

                  --with-hc-pkg='/c/code/HEAD/inplace/bin/ghc-pkg.exe' \

                  --with-hsc2hs='/c/code/HEAD/inplace/bin/hsc2hs.exe' \

                   \

                  --ghc-option=-threaded --prefix='/c/code/HEAD/testsuite/timeout/install-inplace'

Configuring timeout-1...

./Setup build

Preprocessing executable 'timeout' for timeout-1..

Building executable 'timeout' for timeout-1..

[1 of 2] Compiling WinCBindings     ( dist\build\timeout\timeout-tmp\WinCBindings.hs, dist\build\timeout\timeout-tmp\WinCBindings.o )

[2 of 2] Compiling Main             ( timeout.hs, dist\build\timeout\timeout-tmp\Main.o )

Linking dist\build\timeout\timeout.exe ...

./Setup install

Installing executable timeout in C:/code/HEAD/testsuite/timeout/install-inplace\bin

Warning: The directory C:/code/HEAD/testsuite/timeout/install-inplace\bin is

not in the system search path.

make[2]: Leaving directory '/c/code/HEAD/testsuite/timeout'

PYTHON="python3" "python3" ../driver/runtests.py  -e ghc_compiler_always_flags="'-dcore-lint -dcmm-lint -no-user-package-db -rtsopts  -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output'" -e config.compiler_debugged=False -e ghc_with_native_codegen=1 -e config.have_vanilla=True -e config.have_dynamic=False -e config.have_profiling=False -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=0 -e config.have_interp=True -e config.unregisterised=False -e config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=True -e darwin=False -e config.in_tree_compiler=True --threads=5 -e config.cleanup=True -e config.local=False --rootdir=. --configfile=../config/ghc -e 'config.confdir="../config"' -e 'config.platform="x86_64-unknown-mingw32"' -e 'config.os="mingw32"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=".exe"' -e 'config.top="/c/code/HEAD/testsuite"' --config 'compiler="/c/code/HEAD/inplace/bin/ghc-stage2.exe"' --config 'ghc_pkg="/c/code/HEAD/inplace/bin/ghc-pkg.exe"' --config 'haddock="/c/code/HEAD/inplace/bin/haddock.exe"' --config 'hp2ps="/c/code/HEAD/inplace/bin/hp2ps.exe"' --config 'hpc="/c/code/HEAD/inplace/bin/hpc.exe"' --config 'gs="gs"' --config 'timeout_prog="../timeout/install-inplace/bin/timeout.exe"' -e "config.stage=2" --summary-file "../../testsuite_summary.txt" --no-print-summary 1   --rootdir=../../libraries/Win32/tests  --rootdir=../../libraries/array/tests  --rootdir=../../libraries/base/tests  --rootdir=../../libraries/binary/tests  --rootdir=../../libraries/bytestring/tests  --rootdir=../../libraries/containers/tests  --rootdir=../../libraries/deepseq/tests  --rootdir=../../libraries/directory/tests  --rootdir=../../libraries/filepath/tests  --rootdir=../../libraries/ghc-compact/tests  --rootdir=../../libraries/ghc-prim/tests  --rootdir=../../libraries/haskeline/tests  --rootdir=../../libraries/hpc/tests  --rootdir=../../libraries/pretty/tests  --rootdir=../../libraries/process/tests  --rootdir=../../libraries/template-haskell/tests \

      \

      \

      \

      \

      \

      -e config.speed="2" \



Traceback (most recent call last):

  File "../driver/runtests.py", line 189, in <module>

    pkginfo = str(getStdout([config.ghc_pkg, 'dump']))

  File "/c/code/HEAD/testsuite/driver/testutil.py", line 25, in getStdout

    raise Exception("stderr from command: " + str(cmd_and_args))

Exception: stderr from command: ['"/c/code/HEAD/inplace/bin/ghc-pkg.exe"', 'dump']

make[1]: *** [../mk/test.mk:299: test] Error 1

make[1]: Leaving directory '/c/code/HEAD/testsuite/tests'

make: *** [../mk/test.mk:315: fasttest] Error 2

make: Leaving directory '/c/code/HEAD/testsuite/tests'

make: Entering directory '/c/code/HEAD/testsuite/tests/stage1'

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

../../mk/ghc-config "/c/code/HEAD/inplace/bin/ghc-stage1.exe" >"../../mk/ghcconfig_c_code_HEAD_inplace_bin_ghc-stage1.exe.mk"; if [ $? != 0 ]; then rm -f "../../mk/ghcconfig_c_code_HEAD_inplace_bin_ghc-stage1.exe.mk"; exit 1; fi

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

# See Note [validate and testsuite speed] in toplevel Makefile.

make SPEED=2

make[1]: Entering directory '/c/code/HEAD/testsuite/tests/stage1'

WARNING: cache is out of date: C:\code\HEAD\inplace\lib\package.conf.d\package.cache

ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.

PYTHON="python3" "python3" ../../driver/runtests.py  -e ghc_compiler_always_flags="'-dcore-lint -dcmm-lint -no-user-package-db -rtsopts  -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output'" -e config.compiler_debugged=True -e ghc_with_native_codegen=1 -e config.have_vanilla=True -e config.have_dynamic=False -e config.have_profiling=False -e ghc_with_threaded_rts=1 -e ghc_with_dynamic_rts=0 -e config.have_interp=False -e config.unregisterised=False -e config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e ghc_with_smp=1 -e ghc_with_llvm=0 -e windows=True -e darwin=False -e config.in_tree_compiler=True --threads=5 -e config.cleanup=True -e config.local=False --rootdir=. --configfile=../../config/ghc -e 'config.confdir="../../config"' -e 'config.platform="x86_64-unknown-mingw32"' -e 'config.os="mingw32"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=".exe"' -e 'config.top="/c/code/HEAD/testsuite"' --config 'compiler="/c/code/HEAD/inplace/bin/ghc-stage1.exe"' --config 'ghc_pkg="/c/code/HEAD/inplace/bin/ghc-pkg.exe"' --config 'haddock="/c/code/HEAD/inplace/bin/haddock.exe"' --config 'hp2ps="/c/code/HEAD/inplace/bin/hp2ps.exe"' --config 'hpc="/c/code/HEAD/inplace/bin/hpc.exe"' --config 'gs="gs"' --config 'timeout_prog="../../timeout/install-inplace/bin/timeout.exe"' -e "config.stage=1" --summary-file "../../../testsuite_summary_stage1.txt" --no-print-summary 1  \

      \

      \

      \

      \

      \

      -e config.speed="2" \



Traceback (most recent call last):

  File "../../driver/runtests.py", line 189, in <module>

    pkginfo = str(getStdout([config.ghc_pkg, 'dump']))

  File "/c/code/HEAD/testsuite/driver/testutil.py", line 25, in getStdout

    raise Exception("stderr from command: " + str(cmd_and_args))

Exception: stderr from command: ['"/c/code/HEAD/inplace/bin/ghc-pkg.exe"', 'dump']

make[1]: *** [../../mk/test.mk:299: test] Error 1

make[1]: Leaving directory '/c/code/HEAD/testsuite/tests/stage1'

make: *** [../../mk/test.mk:315: fasttest] Error 2

make: Leaving directory '/c/code/HEAD/testsuite/tests/stage1'



==== STAGE 1 TESTS ====

cat: testsuite_summary_stage1.txt: No such file or directory

/c/code/HEAD$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170306/54b3fc09/attachment-0001.html>

From david.macek.0 at gmail.com  Tue Mar  7 08:05:20 2017
From: david.macek.0 at gmail.com (David Macek)
Date: Tue, 7 Mar 2017 09:05:20 +0100
Subject: Windows build broken again
In-Reply-To: <DM2PR21MB00284992F97EE7AD5451402DAD2A0@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <DM2PR21MB00284992F97EE7AD5451402DAD2A0@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <68a903f1-89dd-8e16-3cee-216985875304@gmail.com>

On 4. 3. 2017 22:01, Simon Peyton Jones via ghc-devs wrote:
> Exception: stderr from command: ['"/c/code/HEAD/inplace/bin/ghc-pkg.exe"', 'dump']

Pinpointing the failure. I guess `ghc-pkg dump` is not supposed to write to stderr, but it does. Unfortunately, the test driver doesn't seem to tell us what's the error from ghc-pkg.

-- 
David Macek

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3715 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170307/372ff7c6/attachment.bin>

From lonetiger at gmail.com  Tue Mar  7 08:08:26 2017
From: lonetiger at gmail.com (Phyx)
Date: Tue, 07 Mar 2017 08:08:26 +0000
Subject: Windows build broken again
In-Reply-To: <68a903f1-89dd-8e16-3cee-216985875304@gmail.com>
References: <DM2PR21MB00284992F97EE7AD5451402DAD2A0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <68a903f1-89dd-8e16-3cee-216985875304@gmail.com>
Message-ID: <CABHktDV4EbWbA+c6gWJZZet-6d8ZqgoAa_WPLWG-FOgiL81ARA@mail.gmail.com>

https://ghc.haskell.org/trac/ghc/ticket/13375

On Tue, 7 Mar 2017, 08:05 David Macek, <david.macek.0 at gmail.com> wrote:

> On 4. 3. 2017 22:01, Simon Peyton Jones via ghc-devs wrote:
> > Exception: stderr from command:
> ['"/c/code/HEAD/inplace/bin/ghc-pkg.exe"', 'dump']
>
> Pinpointing the failure. I guess `ghc-pkg dump` is not supposed to write
> to stderr, but it does. Unfortunately, the test driver doesn't seem to tell
> us what's the error from ghc-pkg.
>
> --
> David Macek
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170307/41df66b3/attachment.html>

From mail at joachim-breitner.de  Tue Mar  7 10:42:42 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 07 Mar 2017 11:42:42 +0100
Subject: Better perf
In-Reply-To: <DM2PR21MB00287EB1E6B98C9A1550C897AD2C0@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <DM2PR21MB00287EB1E6B98C9A1550C897AD2C0@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <1488883362.3556.2.camel@joachim-breitner.de>

Hi,

perf.haskell.org has something to say about these:

Am Montag, den 06.03.2017, 15:45 +0000 schrieb Simon Peyton Jones via ghc-devs:
> I’ve just committed this patch sequence
> fb9ae288088a3eabc4e1bb4e86fa473a3881d2e2 Make FloatOut/SetLevels idemoptent on bottoming functions

increases lambda runtime by 3%. Maybe an environment-dependent
performance cliff, given that you did not report this regression in
your nofib listing.

> 995ab74b3c55fe3a0299bd94b49e948c942e76d6 Comments only

No change reported. Good :-)

> 1163f4f2fe9aabd722c963497c67c5f8c71ef71b Tiny refactor

No change reported.

> 9b2c73ea8082199245bfa6a28390b70b38f87fd1 Make TH_Roles2 less fragile

No change reported.

> 9304df5230a7a29d3e992916d133e462b854e55f Fix CSE (again) on literal strings

This is where most of the changes are:
https://perf.haskell.org/ghc/#revision/9304df5230a7a29d3e992916d133e462b854e55f

There are some nice runtime improvements in cryptarithm1 (-12%), fasta,
integer and scs (each -3%).

But: binary-trees runtime increases by 5%.


This was your daily performance weather report.

Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170307/94fe20cf/attachment.sig>

From mail at joachim-breitner.de  Tue Mar  7 13:39:17 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 07 Mar 2017 14:39:17 +0100
Subject: Travis again over time
In-Reply-To: <1488728220.8321.0.camel@joachim-breitner.de>
References: <1488657386.11972.3.camel@joachim-breitner.de>
 <1488728220.8321.0.camel@joachim-breitner.de>
Message-ID: <1488893957.3556.4.camel@joachim-breitner.de>

Hi,

ok, one of these patches brought the build time on Travis down to very
nice 1h again:
https://github.com/ghc/ghc/compare/749740f9c3cb...8ca4bb1ce9d9

The build would be marked as passing if it were not for
integerConstantFolding which is marked as

test('integerConstantFolding',
     [when(compiler_debugged(), expect_broken(11006))], run_command,
     ['$MAKE -s --no-print-directory integerConstantFolding'])

but when Travis runs the build without -DDEBUG, then it still reports
an unexepcted pass, so the compiler_debugged doesn’t quite work as
expected:
https://s3.amazonaws.com/archive.travis-ci.org/jobs/208399920/log.txt

I am not sure why this does not work as expected on travis. If someone
knowledgeable of the test suite driver would like to have a look,
that’d be awesome.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170307/44aece06/attachment.sig>

From david at well-typed.com  Tue Mar  7 18:34:54 2017
From: david at well-typed.com (David Feuer)
Date: Tue, 07 Mar 2017 13:34:54 -0500
Subject: Getting exceptions right
Message-ID: <8771203.AprUWcNyod@squirrel>

I've put together a wiki page describing the issues I think we need to 
address, and laying out the model I think we want to implement for precise 
exceptions. Hopefully, this will help us figure out what we need to do to get a 
better story here.

https://ghc.haskell.org/trac/ghc/wiki/FixingExceptions

Thanks,
David Feuer

From ben at smart-cactus.org  Tue Mar  7 03:04:26 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 06 Mar 2017 22:04:26 -0500
Subject: Windows build broken again
In-Reply-To: <DM2PR21MB0028952D062DE1924F7EADBCAD2C0@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <DM2PR21MB00284992F97EE7AD5451402DAD2A0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <DM2PR21MB0028952D062DE1924F7EADBCAD2C0@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <87k281lrd1.fsf@ben-laptop.smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> Windows build still broken.  Please please could someone fix?
> It's something to do with the testsuite Python script

This is #13375. I have a fix in D3289. It's currently validating.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170306/a9a8ce4c/attachment.sig>

From ben at smart-cactus.org  Tue Mar  7 18:04:53 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 07 Mar 2017 13:04:53 -0500
Subject: Windows build broken again
In-Reply-To: <CABHktDV4EbWbA+c6gWJZZet-6d8ZqgoAa_WPLWG-FOgiL81ARA@mail.gmail.com>
References: <DM2PR21MB00284992F97EE7AD5451402DAD2A0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <68a903f1-89dd-8e16-3cee-216985875304@gmail.com>
 <CABHktDV4EbWbA+c6gWJZZet-6d8ZqgoAa_WPLWG-FOgiL81ARA@mail.gmail.com>
Message-ID: <87efy9kloa.fsf@ben-laptop.smart-cactus.org>

Phyx <lonetiger at gmail.com> writes:

> https://ghc.haskell.org/trac/ghc/ticket/13375
>
Are people not receiving my messages pointing out this ticket? I've
mentioned it twice now but I get the impression that these messages
aren't being seen.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170307/7ad14ad4/attachment.sig>

From ben at smart-cactus.org  Tue Mar  7 03:12:46 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 06 Mar 2017 22:12:46 -0500
Subject: Better perf
In-Reply-To: <DM2PR21MB00287EB1E6B98C9A1550C897AD2C0@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <DM2PR21MB00287EB1E6B98C9A1550C897AD2C0@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <87h935lqz5.fsf@ben-laptop.smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> I've just committed this patch sequence
>
> fb9ae288088a3eabc4e1bb4e86fa473a3881d2e2 Make FloatOut/SetLevels idemoptent on bottoming functions
>
> 995ab74b3c55fe3a0299bd94b49e948c942e76d6 Comments only
>
> 1163f4f2fe9aabd722c963497c67c5f8c71ef71b Tiny refactor
>
> 9b2c73ea8082199245bfa6a28390b70b38f87fd1 Make TH_Roles2 less fragile
>
> 9304df5230a7a29d3e992916d133e462b854e55f Fix CSE (again) on literal strings
> In my final validate run (after updating to HEAD) I saw
>
> Unexpected stat failures:
>
>    perf/space_leaks/T4029.run  T4029 [stat too good] (ghci)
>
This one is rather interesting since I have also been seeing this for
quite some time locally, but Harbormaster consistently disagrees.
Moreover, it passes locally if my machine isn't under load. I
haven't yet investigated why allocations are so inconsistent.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170306/5b952253/attachment.sig>

From lonetiger at gmail.com  Tue Mar  7 18:51:03 2017
From: lonetiger at gmail.com (lonetiger at gmail.com)
Date: Tue, 7 Mar 2017 18:51:03 +0000
Subject: Windows build broken again
In-Reply-To: <87efy9kloa.fsf@ben-laptop.smart-cactus.org>
References: <DM2PR21MB00284992F97EE7AD5451402DAD2A0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <68a903f1-89dd-8e16-3cee-216985875304@gmail.com>
 <CABHktDV4EbWbA+c6gWJZZet-6d8ZqgoAa_WPLWG-FOgiL81ARA@mail.gmail.com>
 <87efy9kloa.fsf@ben-laptop.smart-cactus.org>
Message-ID: <58bf0117.08a7df0a.823b.69bb@mx.google.com>


This last email was the first one I’ve received from you.

From: Ben Gamari
Sent: Tuesday, March 7, 2017 18:50
To: Phyx; David Macek; simonpj at microsoft.com; ghc-devs at haskell.org
Subject: Re: Windows build broken again

Phyx <lonetiger at gmail.com> writes:

> https://ghc.haskell.org/trac/ghc/ticket/13375
>
Are people not receiving my messages pointing out this ticket? I've
mentioned it twice now but I get the impression that these messages
aren't being seen.

Cheers,

- Ben


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170307/cbd2aec6/attachment.html>

From ben at smart-cactus.org  Sat Mar  4 21:45:09 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Sat, 04 Mar 2017 16:45:09 -0500
Subject: Windows build broken again
In-Reply-To: <DM2PR21MB00284992F97EE7AD5451402DAD2A0@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <DM2PR21MB00284992F97EE7AD5451402DAD2A0@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <87tw78lnru.fsf@ben-laptop.smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> The Windows build is broken again.  Here's the tail of the log
>
Yes, I opened a ticket (#13375) about this earlier. Running,

    "C:/msys64/home/ben/ghc/inplace/bin/ghc-pkg.exe" recache

is sufficient to work around the issue it seems.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170304/b1d05abb/attachment.sig>

From simonpj at microsoft.com  Tue Mar  7 20:15:19 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 7 Mar 2017 20:15:19 +0000
Subject: Windows build broken again
In-Reply-To: <87k281lrd1.fsf@ben-laptop.smart-cactus.org>
References: <DM2PR21MB00284992F97EE7AD5451402DAD2A0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <DM2PR21MB0028952D062DE1924F7EADBCAD2C0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <87k281lrd1.fsf@ben-laptop.smart-cactus.org>
Message-ID: <DM2PR21MB00287F759E34E53D58AAFA8FAD2F0@DM2PR21MB0028.namprd21.prod.outlook.com>

| This is #13375. I have a fix in D3289. It's currently validating.

Hooray thank you!  I'm stalled on Windows until you do.

Simon

| -----Original Message-----
| From: Ben Gamari [mailto:ben at smart-cactus.org]
| Sent: 07 March 2017 03:04
| To: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs at haskell.org
| Subject: RE: Windows build broken again
| 
| Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:
| 
| > Windows build still broken.  Please please could someone fix?
| > It's something to do with the testsuite Python script
| 
| This is #13375. I have a fix in D3289. It's currently validating.
| 
| Cheers,
| 
| - Ben

From simonpj at microsoft.com  Tue Mar  7 21:28:27 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 7 Mar 2017 21:28:27 +0000
Subject: Getting exceptions right
In-Reply-To: <8771203.AprUWcNyod@squirrel>
References: <8771203.AprUWcNyod@squirrel>
Message-ID: <DM2PR21MB002876682609D995A8782021AD2F0@DM2PR21MB0028.namprd21.prod.outlook.com>

I have elaborated a bit.

Can you go further to a clear set of proposals?

| -----Original Message-----
| From: David Feuer [mailto:david at well-typed.com]
| Sent: 07 March 2017 18:35
| To: Simon Peyton Jones <simonpj at microsoft.com>
| Cc: ghc-devs at haskell.org
| Subject: Getting exceptions right
| 
| I've put together a wiki page describing the issues I think we need to
| address, and laying out the model I think we want to implement for
| precise exceptions. Hopefully, this will help us figure out what we need
| to do to get a better story here.
| 
| https://ghc.haskell.org/trac/ghc/wiki/FixingExceptions
| 
| Thanks,
| David Feuer

From simonpj at microsoft.com  Tue Mar  7 22:55:17 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 7 Mar 2017 22:55:17 +0000
Subject: Better perf
In-Reply-To: <1488883362.3556.2.camel@joachim-breitner.de>
References: <DM2PR21MB00287EB1E6B98C9A1550C897AD2C0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <1488883362.3556.2.camel@joachim-breitner.de>
Message-ID: <DM2PR21MB002826D3BD40E82E67791B37AD2F0@DM2PR21MB0028.namprd21.prod.outlook.com>

| But: binary-trees runtime increases by 5%.

David: might you look to see if there is any obvious reason for this regression?  We could just accept it, but it's always good to know why, and to document it.

Thanks

Simon

| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Joachim
| Breitner
| Sent: 07 March 2017 10:43
| To: ghc-devs at haskell.org
| Subject: Re: Better perf
| 
| Hi,
| 
| perf.haskell.org has something to say about these:
| 
| Am Montag, den 06.03.2017, 15:45 +0000 schrieb Simon Peyton Jones via
| ghc-devs:
| > I’ve just committed this patch sequence
| > fb9ae288088a3eabc4e1bb4e86fa473a3881d2e2 Make FloatOut/SetLevels
| > idemoptent on bottoming functions
| 
| increases lambda runtime by 3%. Maybe an environment-dependent
| performance cliff, given that you did not report this regression in your
| nofib listing.
| 
| > 995ab74b3c55fe3a0299bd94b49e948c942e76d6 Comments only
| 
| No change reported. Good :-)
| 
| > 1163f4f2fe9aabd722c963497c67c5f8c71ef71b Tiny refactor
| 
| No change reported.
| 
| > 9b2c73ea8082199245bfa6a28390b70b38f87fd1 Make TH_Roles2 less fragile
| 
| No change reported.
| 
| > 9304df5230a7a29d3e992916d133e462b854e55f Fix CSE (again) on literal
| > strings
| 
| This is where most of the changes are:
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fperf.has
| kell.org%2Fghc%2F%23revision%2F9304df5230a7a29d3e992916d133e462b854e55f&d
| ata=02%7C01%7Csimonpj%40microsoft.com%7C68ad9d20aa794e70cdb708d46546c5ff%
| 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244802039385263&sdata=pvj
| YNwtA3NHHxF7z7bwagYX5Cjun8%2FIztPvXEO1AtdY%3D&reserved=0
| 
| There are some nice runtime improvements in cryptarithm1 (-12%), fasta,
| integer and scs (each -3%).
| 
| But: binary-trees runtime increases by 5%.
| 
| 
| This was your daily performance weather report.
| 
| Joachim
| 
| --
| Joachim “nomeata” Breitner
|   mail at joachim-breitner.de •
| https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.joac
| him-
| breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C68ad9d20aa794e70c
| db708d46546c5ff%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636244802039
| 385263&sdata=hbp839x4Boa3J6gY4sOchfHGsLZeHiEsNatxsSv08iQ%3D&reserved=0
|   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
|   Debian Developer: nomeata at debian.org

From simonpj at microsoft.com  Wed Mar  8 12:18:58 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 8 Mar 2017 12:18:58 +0000
Subject: [commit: ghc] master: Deserialize IfaceId more lazily (6446254)
In-Reply-To: <20170303213608.F0E3F3A584@ghc.haskell.org>
References: <20170303213608.F0E3F3A584@ghc.haskell.org>
Message-ID: <BY2PR21MB0020124D1078CA1095FE98B8AD2E0@BY2PR21MB0020.namprd21.prod.outlook.com>

Reid

I beg you to add a comment to these carefully-placed used of laziness!
The informative commit message does not appear in the code :-).

Simon

|  -----Original Message-----
|  From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf
|  Of git at git.haskell.org
|  Sent: 03 March 2017 21:36
|  To: ghc-commits at haskell.org
|  Subject: [commit: ghc] master: Deserialize IfaceId more lazily
|  (6446254)
|  
|  Repository : ssh://git at git.haskell.org/ghc
|  
|  On branch  : master
|  Link       :
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha
|  skell.org%2Ftrac%2Fghc%2Fchangeset%2F644625449a9b6fbeb9a81f1a7d0e7d184
|  24fb707%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C9b1a8ffea4684b8
|  f5e7608d4627d690f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362417
|  38152433434&sdata=H81TTDPPgdp%2BYQzqRFUtiyyfm%2Fn6YRQT%2BoOpJuehsOU%3D
|  &reserved=0
|  
|  >---------------------------------------------------------------
|  
|  commit 644625449a9b6fbeb9a81f1a7d0e7d18424fb707
|  Author: Reid Barton <rwbarton at gmail.com>
|  Date:   Fri Mar 3 15:49:38 2017 -0500
|  
|      Deserialize IfaceId more lazily
|  
|      This change sped up the total validate --build-only time by 0.8%
|      on my test system; hopefully a representative result.
|  
|      I didn't bother making the other constructors lazy because for
|      IfaceData and IfaceClass we need to pull on some of the fields
|      in loadDecl, and all the others seem much more rare than IfaceId.
|  
|      Test Plan: validate, perf
|  
|      Reviewers: austin, bgamari
|  
|      Reviewed By: bgamari
|  
|      Subscribers: thomie
|  
|      Differential Revision: https://phabricator.haskell.org/D3269
|  
|  
|  >---------------------------------------------------------------
|  
|  644625449a9b6fbeb9a81f1a7d0e7d18424fb707
|   compiler/iface/IfaceSyn.hs | 8 ++------
|   1 file changed, 2 insertions(+), 6 deletions(-)
|  
|  diff --git a/compiler/iface/IfaceSyn.hs b/compiler/iface/IfaceSyn.hs
|  index d73a738..1c30476 100644
|  --- a/compiler/iface/IfaceSyn.hs
|  +++ b/compiler/iface/IfaceSyn.hs
|  @@ -1565,9 +1565,7 @@ instance Binary IfaceDecl where
|       put_ bh (IfaceId name ty details idinfo) = do
|           putByte bh 0
|           putIfaceTopBndr bh name
|  -        put_ bh ty
|  -        put_ bh details
|  -        put_ bh idinfo
|  +        lazyPut bh (ty, details, idinfo)
|  
|       put_ bh (IfaceData a1 a2 a3 a4 a5 a6 a7 a8 a9) = do
|           putByte bh 2
|  @@ -1657,9 +1655,7 @@ instance Binary IfaceDecl where
|           h <- getByte bh
|           case h of
|               0 -> do name    <- get bh
|  -                    ty      <- get bh
|  -                    details <- get bh
|  -                    idinfo  <- get bh
|  +                    ~(ty, details, idinfo) <- lazyGet bh
|                       return (IfaceId name ty details idinfo)
|               1 -> error "Binary.get(TyClDecl): ForeignType"
|               2 -> do a1  <- getIfaceTopBndr bh
|  
|  _______________________________________________
|  ghc-commits mailing list
|  ghc-commits at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  commits&data=02%7C01%7Csimonpj%40microsoft.com%7C9b1a8ffea4684b8f5e760
|  8d4627d690f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362417381524
|  33434&sdata=L1dvXY%2BW%2Brv4gMqeWm8BGfIPifKK0DBndoJVF%2FCfu0c%3D&reser
|  ved=0

From simonpj at microsoft.com  Wed Mar  8 12:22:55 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 8 Mar 2017 12:22:55 +0000
Subject: =?utf-8?B?UkU6IFtjb21taXQ6IGdoY10gbWFzdGVyOiBBZGQgcnVsZSBtYXBGQiBjICg=?=
 =?utf-8?B?zrt4LngpID0gYyAoMmZhNDQyMSk=?=
In-Reply-To: <20170306235140.D58513A584@ghc.haskell.org>
References: <20170306235140.D58513A584@ghc.haskell.org>
Message-ID: <BY2PR21MB0020AC0D106F2AAC6BF493B9AD2E0@BY2PR21MB0020.namprd21.prod.outlook.com>

Joachim

Please, I beg you, add a comment to explain why this rule is useful. I'm sure you had a good reason for adding it, but it's not apparent from the code.

Thanks

Simon

|  -----Original Message-----
|  From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf
|  Of git at git.haskell.org
|  Sent: 06 March 2017 23:52
|  To: ghc-commits at haskell.org
|  Subject: [commit: ghc] master: Add rule mapFB c (λx.x) = c (2fa4421)
|  
|  Repository : ssh://git at git.haskell.org/ghc
|  
|  On branch  : master
|  Link       :
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha
|  skell.org%2Ftrac%2Fghc%2Fchangeset%2F2fa44217c1d9722227297eefb0d6c6aed
|  7e128ca%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7Cc5db3687da004cd
|  11d0f08d464ebc6ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362444
|  11212143808&sdata=KMHS17MUXQUkBOaMbFiRxXiRM8gIvlEMGz%2FDw7F7Njo%3D&res
|  erved=0
|  
|  >---------------------------------------------------------------
|  
|  commit 2fa44217c1d9722227297eefb0d6c6aed7e128ca
|  Author: Joachim Breitner <mail at joachim-breitner.de>
|  Date:   Mon Mar 6 17:30:52 2017 -0500
|  
|      Add rule mapFB c (λx.x) = c
|  
|      Test Plan: exended T2110 with a case for that.
|  
|      Reviewers: austin, hvr, dfeuer, bgamari
|  
|      Reviewed By: dfeuer
|  
|      Subscribers: dfeuer, thomie
|  
|      Differential Revision: https://phabricator.haskell.org/D3275
|  
|  
|  >---------------------------------------------------------------
|  
|  2fa44217c1d9722227297eefb0d6c6aed7e128ca
|   libraries/base/GHC/Base.hs                        | 1 +
|   testsuite/tests/simplCore/should_run/T2110.hs     | 3 +++
|   testsuite/tests/simplCore/should_run/T2110.stdout | 1 +
|   3 files changed, 5 insertions(+)
|  
|  diff --git a/libraries/base/GHC/Base.hs b/libraries/base/GHC/Base.hs
|  index 2f155c6..6f9d454 100644
|  --- a/libraries/base/GHC/Base.hs
|  +++ b/libraries/base/GHC/Base.hs
|  @@ -973,6 +973,7 @@ mapFB c f = \x ys -> c (f x) ys
|   "map"       [~1] forall f xs.   map f xs                = build (\c n
|  -> foldr (mapFB c f) n xs)
|   "mapList"   [1]  forall f.      foldr (mapFB (:) f) []  = map f
|   "mapFB"     forall c f g.       mapFB (mapFB c f) g     = mapFB c
|  (f.g)
|  +"mapFB/id"  forall c.           mapFB c (\x -> x)       = c
|     #-}
|  
|   -- See Breitner, Eisenberg, Peyton Jones, and Weirich, "Safe Zero-
|  cost diff --git a/testsuite/tests/simplCore/should_run/T2110.hs
|  b/testsuite/tests/simplCore/should_run/T2110.hs
|  index 610be09..d945fac 100644
|  --- a/testsuite/tests/simplCore/should_run/T2110.hs
|  +++ b/testsuite/tests/simplCore/should_run/T2110.hs
|  @@ -5,6 +5,8 @@ import Unsafe.Coerce
|  
|   newtype Age = Age Int
|  
|  +foo :: [Int] -> [Int]
|  +foo = map id
|   fooAge :: [Int] -> [Age]
|   fooAge = map Age
|   fooCoerce :: [Int] -> [Age]
|  @@ -19,6 +21,7 @@ same x y = case reallyUnsafePtrEquality#
|  (unsafeCoerce x) y of
|  
|   main = do
|       let l = [1,2,3]
|  +    same (foo l) l
|       same (fooAge l) l
|       same (fooCoerce l) l
|       same (fooUnsafeCoerce l) l
|  diff --git a/testsuite/tests/simplCore/should_run/T2110.stdout
|  b/testsuite/tests/simplCore/should_run/T2110.stdout
|  index 55f7ebb..4ff957b 100644
|  --- a/testsuite/tests/simplCore/should_run/T2110.stdout
|  +++ b/testsuite/tests/simplCore/should_run/T2110.stdout
|  @@ -1,3 +1,4 @@
|   yes
|   yes
|   yes
|  +yes
|  
|  _______________________________________________
|  ghc-commits mailing list
|  ghc-commits at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  commits&data=02%7C01%7Csimonpj%40microsoft.com%7Cc5db3687da004cd11d0f0
|  8d464ebc6ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362444112121
|  43808&sdata=y%2BRYDSeV9k2Uj%2BlPtE%2BeIeG05mQvE97QV0B0wgl7cx4%3D&reser
|  ved=0

From simonpj at microsoft.com  Wed Mar  8 13:17:32 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 8 Mar 2017 13:17:32 +0000
Subject: Better conditionals
Message-ID: <BY2PR21MB002008E512DB658C9B93C6C8AD2E0@BY2PR21MB0020.namprd21.prod.outlook.com>

Reid
As promised: could you look at Trac #13397, re tagToEnum#.
In particular, why is n-body running slower??
The change is basically a good one: removes a nasty special case in the code generator and de-clutters the code generally.  So I'm keen to keep it.
Not important for 8.2 though.
Thanks
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170308/fc8414a4/attachment.html>

From mail at joachim-breitner.de  Wed Mar  8 13:21:30 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 08 Mar 2017 14:21:30 +0100
Subject: =?UTF-8?Q?RE=3A_=5Bcommit=3A_ghc=5D_master=3A_Add_r?=
 =?UTF-8?Q?ule_mapFB_c_=28=CE=BBx=2Ex=29_=3D_c_=282fa4421=29?=
In-Reply-To: <BY2PR21MB0020AC0D106F2AAC6BF493B9AD2E0@BY2PR21MB0020.namprd21.prod.outlook.com>
References: <20170306235140.D58513A584@ghc.haskell.org>
 <BY2PR21MB0020AC0D106F2AAC6BF493B9AD2E0@BY2PR21MB0020.namprd21.prod.outlook.com>
Message-ID: <C006CA16-E2C8-446F-9859-2F2B54C3455F@joachim-breitner.de>

Hi,

I guess you are right. I should also be more careful about distinguishing Phab DR that I create to get feedback from CI and review, even before I do such non-functional polishing of the patch, and ready-to-apply changes (which I'd commit myself anyways).

Joachim 




Am 8. März 2017 13:22:55 MEZ schrieb Simon Peyton Jones <simonpj at microsoft.com>:
>Joachim
>
>Please, I beg you, add a comment to explain why this rule is useful.
>I'm sure you had a good reason for adding it, but it's not apparent
>from the code.
>
>Thanks
>
>Simon
>
>|  -----Original Message-----
>|  From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf
>|  Of git at git.haskell.org
>|  Sent: 06 March 2017 23:52
>|  To: ghc-commits at haskell.org
>|  Subject: [commit: ghc] master: Add rule mapFB c (λx.x) = c (2fa4421)
>|  
>|  Repository : ssh://git at git.haskell.org/ghc
>|  
>|  On branch  : master
>|  Link       :
>| 
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha
>| 
>skell.org%2Ftrac%2Fghc%2Fchangeset%2F2fa44217c1d9722227297eefb0d6c6aed
>| 
>7e128ca%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7Cc5db3687da004cd
>| 
>11d0f08d464ebc6ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362444
>| 
>11212143808&sdata=KMHS17MUXQUkBOaMbFiRxXiRM8gIvlEMGz%2FDw7F7Njo%3D&res
>|  erved=0
>|  
>|  >---------------------------------------------------------------
>|  
>|  commit 2fa44217c1d9722227297eefb0d6c6aed7e128ca
>|  Author: Joachim Breitner <mail at joachim-breitner.de>
>|  Date:   Mon Mar 6 17:30:52 2017 -0500
>|  
>|      Add rule mapFB c (λx.x) = c
>|  
>|      Test Plan: exended T2110 with a case for that.
>|  
>|      Reviewers: austin, hvr, dfeuer, bgamari
>|  
>|      Reviewed By: dfeuer
>|  
>|      Subscribers: dfeuer, thomie
>|  
>|      Differential Revision: https://phabricator.haskell.org/D3275
>|  
>|  
>|  >---------------------------------------------------------------
>|  
>|  2fa44217c1d9722227297eefb0d6c6aed7e128ca
>|   libraries/base/GHC/Base.hs                        | 1 +
>|   testsuite/tests/simplCore/should_run/T2110.hs     | 3 +++
>|   testsuite/tests/simplCore/should_run/T2110.stdout | 1 +
>|   3 files changed, 5 insertions(+)
>|  
>|  diff --git a/libraries/base/GHC/Base.hs b/libraries/base/GHC/Base.hs
>|  index 2f155c6..6f9d454 100644
>|  --- a/libraries/base/GHC/Base.hs
>|  +++ b/libraries/base/GHC/Base.hs
>|  @@ -973,6 +973,7 @@ mapFB c f = \x ys -> c (f x) ys
>|   "map"       [~1] forall f xs.   map f xs                = build (\c
>n
>|  -> foldr (mapFB c f) n xs)
>|   "mapList"   [1]  forall f.      foldr (mapFB (:) f) []  = map f
>|   "mapFB"     forall c f g.       mapFB (mapFB c f) g     = mapFB c
>|  (f.g)
>|  +"mapFB/id"  forall c.           mapFB c (\x -> x)       = c
>|     #-}
>|  
>|   -- See Breitner, Eisenberg, Peyton Jones, and Weirich, "Safe Zero-
>|  cost diff --git a/testsuite/tests/simplCore/should_run/T2110.hs
>|  b/testsuite/tests/simplCore/should_run/T2110.hs
>|  index 610be09..d945fac 100644
>|  --- a/testsuite/tests/simplCore/should_run/T2110.hs
>|  +++ b/testsuite/tests/simplCore/should_run/T2110.hs
>|  @@ -5,6 +5,8 @@ import Unsafe.Coerce
>|  
>|   newtype Age = Age Int
>|  
>|  +foo :: [Int] -> [Int]
>|  +foo = map id
>|   fooAge :: [Int] -> [Age]
>|   fooAge = map Age
>|   fooCoerce :: [Int] -> [Age]
>|  @@ -19,6 +21,7 @@ same x y = case reallyUnsafePtrEquality#
>|  (unsafeCoerce x) y of
>|  
>|   main = do
>|       let l = [1,2,3]
>|  +    same (foo l) l
>|       same (fooAge l) l
>|       same (fooCoerce l) l
>|       same (fooUnsafeCoerce l) l
>|  diff --git a/testsuite/tests/simplCore/should_run/T2110.stdout
>|  b/testsuite/tests/simplCore/should_run/T2110.stdout
>|  index 55f7ebb..4ff957b 100644
>|  --- a/testsuite/tests/simplCore/should_run/T2110.stdout
>|  +++ b/testsuite/tests/simplCore/should_run/T2110.stdout
>|  @@ -1,3 +1,4 @@
>|   yes
>|   yes
>|   yes
>|  +yes
>|  
>|  _______________________________________________
>|  ghc-commits mailing list
>|  ghc-commits at haskell.org
>| 
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
>|  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
>| 
>commits&data=02%7C01%7Csimonpj%40microsoft.com%7Cc5db3687da004cd11d0f0
>| 
>8d464ebc6ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362444112121
>| 
>43808&sdata=y%2BRYDSeV9k2Uj%2BlPtE%2BeIeG05mQvE97QV0B0wgl7cx4%3D&reser
>|  ved=0

From rwbarton at gmail.com  Wed Mar  8 20:46:18 2017
From: rwbarton at gmail.com (Reid Barton)
Date: Wed, 8 Mar 2017 15:46:18 -0500
Subject: [commit: ghc] master: Deserialize IfaceId more lazily (6446254)
In-Reply-To: <BY2PR21MB0020124D1078CA1095FE98B8AD2E0@BY2PR21MB0020.namprd21.prod.outlook.com>
References: <20170303213608.F0E3F3A584@ghc.haskell.org>
 <BY2PR21MB0020124D1078CA1095FE98B8AD2E0@BY2PR21MB0020.namprd21.prod.outlook.com>
Message-ID: <CADmwj45uMQBpa-yrrGKY3+O-8XE_3dQFr_CfMnGaRPGmRMqHLw@mail.gmail.com>

Done in commit fdb594ed3286088c1a46c95f29e277fcc60c0a01.

Regards,
Reid

On Wed, Mar 8, 2017 at 7:18 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> Reid
>
> I beg you to add a comment to these carefully-placed used of laziness!
> The informative commit message does not appear in the code :-).
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf
> |  Of git at git.haskell.org
> |  Sent: 03 March 2017 21:36
> |  To: ghc-commits at haskell.org
> |  Subject: [commit: ghc] master: Deserialize IfaceId more lazily
> |  (6446254)
> |
> |  Repository : ssh://git at git.haskell.org/ghc
> |
> |  On branch  : master
> |  Link       :
> |  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha
> |  skell.org%2Ftrac%2Fghc%2Fchangeset%2F644625449a9b6fbeb9a81f1a7d0e7d184
> |  24fb707%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C9b1a8ffea4684b8
> |  f5e7608d4627d690f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362417
> |  38152433434&sdata=H81TTDPPgdp%2BYQzqRFUtiyyfm%2Fn6YRQT%2BoOpJuehsOU%3D
> |  &reserved=0
> |
> |  >---------------------------------------------------------------
> |
> |  commit 644625449a9b6fbeb9a81f1a7d0e7d18424fb707
> |  Author: Reid Barton <rwbarton at gmail.com>
> |  Date:   Fri Mar 3 15:49:38 2017 -0500
> |
> |      Deserialize IfaceId more lazily
> |
> |      This change sped up the total validate --build-only time by 0.8%
> |      on my test system; hopefully a representative result.
> |
> |      I didn't bother making the other constructors lazy because for
> |      IfaceData and IfaceClass we need to pull on some of the fields
> |      in loadDecl, and all the others seem much more rare than IfaceId.
> |
> |      Test Plan: validate, perf
> |
> |      Reviewers: austin, bgamari
> |
> |      Reviewed By: bgamari
> |
> |      Subscribers: thomie
> |
> |      Differential Revision: https://phabricator.haskell.org/D3269
> |
> |
> |  >---------------------------------------------------------------
> |
> |  644625449a9b6fbeb9a81f1a7d0e7d18424fb707
> |   compiler/iface/IfaceSyn.hs | 8 ++------
> |   1 file changed, 2 insertions(+), 6 deletions(-)
> |
> |  diff --git a/compiler/iface/IfaceSyn.hs b/compiler/iface/IfaceSyn.hs
> |  index d73a738..1c30476 100644
> |  --- a/compiler/iface/IfaceSyn.hs
> |  +++ b/compiler/iface/IfaceSyn.hs
> |  @@ -1565,9 +1565,7 @@ instance Binary IfaceDecl where
> |       put_ bh (IfaceId name ty details idinfo) = do
> |           putByte bh 0
> |           putIfaceTopBndr bh name
> |  -        put_ bh ty
> |  -        put_ bh details
> |  -        put_ bh idinfo
> |  +        lazyPut bh (ty, details, idinfo)
> |
> |       put_ bh (IfaceData a1 a2 a3 a4 a5 a6 a7 a8 a9) = do
> |           putByte bh 2
> |  @@ -1657,9 +1655,7 @@ instance Binary IfaceDecl where
> |           h <- getByte bh
> |           case h of
> |               0 -> do name    <- get bh
> |  -                    ty      <- get bh
> |  -                    details <- get bh
> |  -                    idinfo  <- get bh
> |  +                    ~(ty, details, idinfo) <- lazyGet bh
> |                       return (IfaceId name ty details idinfo)
> |               1 -> error "Binary.get(TyClDecl): ForeignType"
> |               2 -> do a1  <- getIfaceTopBndr bh
> |
> |  _______________________________________________
> |  ghc-commits mailing list
> |  ghc-commits at haskell.org
> |  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
> |  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  commits&data=02%7C01%7Csimonpj%40microsoft.com%7C9b1a8ffea4684b8f5e760
> |  8d4627d690f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362417381524
> |  33434&sdata=L1dvXY%2BW%2Brv4gMqeWm8BGfIPifKK0DBndoJVF%2FCfu0c%3D&reser
> |  ved=0

From mail at joachim-breitner.de  Thu Mar  9 15:10:19 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 09 Mar 2017 16:10:19 +0100
Subject: Better perf
In-Reply-To: <DM2PR21MB002826D3BD40E82E67791B37AD2F0@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <DM2PR21MB00287EB1E6B98C9A1550C897AD2C0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <1488883362.3556.2.camel@joachim-breitner.de>
 <DM2PR21MB002826D3BD40E82E67791B37AD2F0@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <1489072219.3241.1.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 07.03.2017, 22:55 +0000 schrieb Simon Peyton Jones via
ghc-devs:
> > But: binary-trees runtime increases by 5%.
> 
> David: might you look to see if there is any obvious reason for this
> regression?  We could just accept it, but it's always good to know
> why, and to document it.

Turns out that my commit
Add rule mapFB c (λx.x) = c
fixed that regression:
https://perf.haskell.org/ghc/#revision/2fa44217c1d9722227297eefb0d6c6aed7e128ca

Maybe there is just a performance cliff there, and these jumps don’t
really mean anything.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/003d787d/attachment.sig>

From simonpj at microsoft.com  Thu Mar  9 15:17:06 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 9 Mar 2017 15:17:06 +0000
Subject: Better perf
In-Reply-To: <1489072219.3241.1.camel@joachim-breitner.de>
References: <DM2PR21MB00287EB1E6B98C9A1550C897AD2C0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <1488883362.3556.2.camel@joachim-breitner.de>
 <DM2PR21MB002826D3BD40E82E67791B37AD2F0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <1489072219.3241.1.camel@joachim-breitner.de>
Message-ID: <DM2PR21MB002896363D62241D1F2C0A0BAD210@DM2PR21MB0028.namprd21.prod.outlook.com>

Interesting!

I keep nofib/Simon-nofib-notes for per-benchmark notes on perf.

Would you like to add a note for 'binary-trees' pointing to these emails?  So if someone later is looking for perf changes in binary-trees, they have some back-pointers to chase up.

Thanks

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Joachim Breitner
|  Sent: 09 March 2017 15:10
|  To: ghc-devs at haskell.org
|  Subject: Re: Better perf
|  
|  Hi,
|  
|  Am Dienstag, den 07.03.2017, 22:55 +0000 schrieb Simon Peyton Jones
|  via
|  ghc-devs:
|  > > But: binary-trees runtime increases by 5%.
|  >
|  > David: might you look to see if there is any obvious reason for this
|  > regression?  We could just accept it, but it's always good to know
|  > why, and to document it.
|  
|  Turns out that my commit
|  Add rule mapFB c (λx.x) = c
|  fixed that regression:
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fperf.
|  haskell.org%2Fghc%2F%23revision%2F2fa44217c1d9722227297eefb0d6c6aed7e1
|  28ca&data=02%7C01%7Csimonpj%40microsoft.com%7C874797bc62de4b6aecf208d4
|  66fe7720%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362466904875493
|  08&sdata=ysGORaGgIlhCc88uQHB3v0sh5LNWhFY06iSgnTm6Pgo%3D&reserved=0
|  
|  Maybe there is just a performance cliff there, and these jumps don’t
|  really mean anything.
|  
|  Greetings,
|  Joachim
|  
|  --
|  Joachim “nomeata” Breitner
|    mail at joachim-breitner.de •
|  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C874797bc62de4b
|  6aecf208d466fe7720%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636246
|  690487549308&sdata=HxOTFdoh4hIqXVbPCgZOwMjob%2B572b1ymbAdBEXTF6A%3D&re
|  served=0
|    XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
|    Debian Developer: nomeata at debian.org

From simonpj at microsoft.com  Thu Mar  9 15:21:43 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 9 Mar 2017 15:21:43 +0000
Subject: [commit: ghc] master: Add a comment to the mapFB rules (665cefe)
In-Reply-To: <20170309151402.036983A584@ghc.haskell.org>
References: <20170309151402.036983A584@ghc.haskell.org>
Message-ID: <DM2PR21MB00285036B5661894CFCFB004AD210@DM2PR21MB0028.namprd21.prod.outlook.com>

|  +-- The "mapFB" rule optimises compositions of map and
|  +-- the "mapFB/id" rule get rids of 'map id' calls.
|  +-- (Any similarity to the Functor laws for [] is expected.)

Yes, obviously.  But did you have a use-case, or did you just to this on principle?  If you don't have this rule what goes wrong.  You must have had a proximate reason for adding it.

Oh. And I've just realised that 
   mapFB c id
will turn into
   \x y. c x y
as soon as you inline mapFB. So why do you need a RULE to do that?  Why not leave it for the inliner?

Simon


|  -----Original Message-----
|  From: ghc-commits [mailto:ghc-commits-bounces at haskell.org] On Behalf
|  Of git at git.haskell.org
|  Sent: 09 March 2017 15:14
|  To: ghc-commits at haskell.org
|  Subject: [commit: ghc] master: Add a comment to the mapFB rules
|  (665cefe)
|  
|  Repository : ssh://git at git.haskell.org/ghc
|  
|  On branch  : master
|  Link       :
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.ha
|  skell.org%2Ftrac%2Fghc%2Fchangeset%2F665cefe80d112ed2e4fb9617d277a1466
|  e83f9bd%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C8854d69a18b4459
|  e528808d466feef08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362466
|  92510080066&sdata=IR%2BftPvaSs2xZa74FEWe67ynoP6bgLKOExK7jtPe4Yg%3D&res
|  erved=0
|  
|  >---------------------------------------------------------------
|  
|  commit 665cefe80d112ed2e4fb9617d277a1466e83f9bd
|  Author: Joachim Breitner <mail at joachim-breitner.de>
|  Date:   Thu Mar 9 16:13:08 2017 +0100
|  
|      Add a comment to the mapFB rules
|  
|      to amend 2fa44217c1d9722227297eefb0d6c6aed7e128ca.
|  
|  
|  >---------------------------------------------------------------
|  
|  665cefe80d112ed2e4fb9617d277a1466e83f9bd
|   libraries/base/GHC/Base.hs | 6 ++++--
|   1 file changed, 4 insertions(+), 2 deletions(-)
|  
|  diff --git a/libraries/base/GHC/Base.hs b/libraries/base/GHC/Base.hs
|  index 6f9d454..a678c22 100644
|  --- a/libraries/base/GHC/Base.hs
|  +++ b/libraries/base/GHC/Base.hs
|  @@ -964,10 +964,12 @@ mapFB c f = \x ys -> c (f x) ys
|   -- (along with build's unfolding) else we'd get an infinite loop
|   -- in the rules.  Hence the activation control below.
|   --
|  --- The "mapFB" rule optimises compositions of map.
|  ---
|   -- This same pattern is followed by many other functions:
|   -- e.g. append, filter, iterate, repeat, etc.
|  +--
|  +-- The "mapFB" rule optimises compositions of map and
|  +-- the "mapFB/id" rule get rids of 'map id' calls.
|  +-- (Any similarity to the Functor laws for [] is expected.)
|  
|   {-# RULES
|   "map"       [~1] forall f xs.   map f xs                = build (\c n
|  -> foldr (mapFB c f) n xs)
|  
|  _______________________________________________
|  ghc-commits mailing list
|  ghc-commits at haskell.org
|  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
|  askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
|  commits&data=02%7C01%7Csimonpj%40microsoft.com%7C8854d69a18b4459e52880
|  8d466feef08%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6362466925100
|  80066&sdata=cU6XkSWb5Lg1oaEnVPwB2%2BesI9jtneA2051MhD4SnnM%3D&reserved=
|  0

From mail at joachim-breitner.de  Thu Mar  9 15:56:13 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 09 Mar 2017 16:56:13 +0100
Subject: [commit: ghc] master: Add a comment to the mapFB rules (665cefe)
In-Reply-To: <DM2PR21MB00285036B5661894CFCFB004AD210@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <20170309151402.036983A584@ghc.haskell.org>
 <DM2PR21MB00285036B5661894CFCFB004AD210@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <1489074973.3241.3.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 09.03.2017, 15:21 +0000 schrieb Simon Peyton Jones
via ghc-devs:
> >  +-- The "mapFB" rule optimises compositions of map and
> >  +-- the "mapFB/id" rule get rids of 'map id' calls.
> >  +-- (Any similarity to the Functor laws for [] is expected.)
> 
> Yes, obviously.  But did you have a use-case, or did you just to this
> on principle?  If you don't have this rule what goes wrong.  You must
> have had a proximate reason for adding it.

Just on principle. I saw "map id" in some code dump and thought that
this should not be there.

> Oh. And I've just realised that 
>    mapFB c id
> will turn into
>    \x y. c x y
> as soon as you inline mapFB. So why do you need a RULE to do
> that?  Why not leave it for the inliner?

Because we have to keep mapFB around to rewrite it back with this rule
 "mapList"   [1]  forall f.      foldr (mapFB (:) f) []  = map f

This is explained in Note [Inline FB functions] in GHC.List, which is
referenced from the
{-# INLINE [0] mapFB #-}
pragma.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/1479b27f/attachment.sig>

From simonpj at microsoft.com  Thu Mar  9 16:26:42 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 9 Mar 2017 16:26:42 +0000
Subject: Windows build failing in a new way
Message-ID: <DM2PR21MB00289E6687BBF27225FFCBA7AD210@DM2PR21MB0028.namprd21.prod.outlook.com>

My windows build is more broken than usual.  I can't even build a GHC.
Please, could someone fix this?  I'm getting desperate.
Simon


libtool: compile:  C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -Wall -Werror -fno-stack-protector -w -fexceptions -MT src/x86/ffi64.lo -MMD -MP -MF src/x86/.deps/ffi64.Tpo -c ../src/x86/ffi64.c -o src/x86/ffi64.o

depbase=`echo src/x86/unix64.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\

/bin/sh ./libtool    --mode=compile C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H -I. -I..  -I. -I../include -Iinclude -I../src  -I. -I../include -Iinclude -I../src -Wall -Werror -fno-stack-protector -w -MT src/x86/unix64.lo -MMD -MP -MF $depbase.Tpo -c -o src/x86/unix64.lo ../src/x86/unix64.S &&\

mv -f $depbase.Tpo $depbase.Plo

libtool: compile:  C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -I. -I../include -Iinclude -I../src -Wall -Werror -fno-stack-protector -w -MT src/x86/unix64.lo -MMD -MP -MF src/x86/.deps/unix64.Tpo -c ../src/x86/unix64.S -o src/x86/unix64.o

../src/x86/unix64.S: Assembler messages:

../src/x86/unix64.S:45: Error: junk at end of line, first unrecognized character is `f'

../src/x86/unix64.S:204: Error: junk at end of line, first unrecognized character is `f'

../src/x86/unix64.S:208: Error: junk at end of line, first unrecognized character is `f'

../src/x86/unix64.S:326: Error: junk at end of line, first unrecognized character is `f'

../src/x86/unix64.S:334: Error: junk at end of line, first unrecognized character is `,'

make[5]: *** [Makefile:1335: src/x86/unix64.lo] Error 1

make[5]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'

make[4]: *** [Makefile:1596: all-recursive] Error 1

make[4]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'

make[3]: *** [Makefile:730: all] Error 2

make[3]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'

make[2]: *** [Makefile:608: all-all] Error 2

rts/ghc.mk:494: rts/dist/build/.depend-v-l-debug-thr-thr_debug-thr_l.c_asm: No such file or directory

make[1]: *** [libffi/ghc.mk:115: libffi/stamp.ffi.static.build] Error 2

make: *** [Makefile:127: all] Error 2

/c/code/HEAD$
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/a7b59528/attachment-0001.html>

From lonetiger at gmail.com  Thu Mar  9 16:38:19 2017
From: lonetiger at gmail.com (Phyx)
Date: Thu, 09 Mar 2017 16:38:19 +0000
Subject: Windows build failing in a new way
In-Reply-To: <DM2PR21MB00289E6687BBF27225FFCBA7AD210@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <DM2PR21MB00289E6687BBF27225FFCBA7AD210@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <CABHktDW87XUgk1ZeO481Fnijh4B4EF6-zLmdwdufUm4q3tHzxQ@mail.gmail.com>

Hi Simon,

As of this morning the Windows build was working fine
https://github.com/Mistuke/GhcWindowsBuild/commit/aa6906b2535224721d8b049cee3edcd938c3e951
those are my nightly logs for last night at commit a02b80f

That error seems to be coming from gcc and not ghc. We did update the crt
and maybe the scripts didn't do the right thing. Could you try nuking
ghc-tarballs and trying again? Of course running with -
-enable-tarballs-autodownloads on.

Tamar

On Thu, 9 Mar 2017, 16:28 Simon Peyton Jones via ghc-devs, <
ghc-devs at haskell.org> wrote:

> My windows build is more broken than usual.  I can’t even build a GHC.
>
> Please, could someone fix this?  I’m getting desperate.
>
> Simon
>
>
>
> libtool: compile:  C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H
> -I. -I.. -I. -I../include -Iinclude -I../src -Wall -Werror
> -fno-stack-protector -w -fexceptions -MT src/x86/ffi64.lo -MMD -MP -MF
> src/x86/.deps/ffi64.Tpo -c ../src/x86/ffi64.c -o src/x86/ffi64.o
>
> depbase=`echo src/x86/unix64.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
>
> /bin/sh ./libtool    --mode=compile C:/code/HEAD/inplace/mingw/bin/gcc.exe
> -DHAVE_CONFIG_H -I. -I..  -I. -I../include -Iinclude -I../src  -I.
> -I../include -Iinclude -I../src -Wall -Werror -fno-stack-protector -w -MT
> src/x86/unix64.lo -MMD -MP -MF $depbase.Tpo -c -o src/x86/unix64.lo
> ../src/x86/unix64.S &&\
>
> mv -f $depbase.Tpo $depbase.Plo
>
> libtool: compile:  C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H
> -I. -I.. -I. -I../include -Iinclude -I../src -I. -I../include -Iinclude
> -I../src -Wall -Werror -fno-stack-protector -w -MT src/x86/unix64.lo -MMD
> -MP -MF src/x86/.deps/unix64.Tpo -c ../src/x86/unix64.S -o src/x86/unix64.o
>
> ../src/x86/unix64.S: Assembler messages:
>
> ../src/x86/unix64.S:45: Error: junk at end of line, first unrecognized
> character is `f'
>
> ../src/x86/unix64.S:204: Error: junk at end of line, first unrecognized
> character is `f'
>
> ../src/x86/unix64.S:208: Error: junk at end of line, first unrecognized
> character is `f'
>
> ../src/x86/unix64.S:326: Error: junk at end of line, first unrecognized
> character is `f'
>
> ../src/x86/unix64.S:334: Error: junk at end of line, first unrecognized
> character is `,'
>
> make[5]: *** [Makefile:1335: src/x86/unix64.lo] Error 1
>
> make[5]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'
>
> make[4]: *** [Makefile:1596: all-recursive] Error 1
>
> make[4]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'
>
> make[3]: *** [Makefile:730: all] Error 2
>
> make[3]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'
>
> make[2]: *** [Makefile:608: all-all] Error 2
>
> rts/ghc.mk:494:
> rts/dist/build/.depend-v-l-debug-thr-thr_debug-thr_l.c_asm: No such file or
> directory
>
> make[1]: *** [libffi/ghc.mk:115: libffi/stamp.ffi.static.build] Error 2
>
> make: *** [Makefile:127: all] Error 2
>
> /c/code/HEAD$
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/b43705d3/attachment.html>

From lonetiger at gmail.com  Thu Mar  9 17:11:37 2017
From: lonetiger at gmail.com (Phyx)
Date: Thu, 09 Mar 2017 17:11:37 +0000
Subject: Windows build failing in a new way
In-Reply-To: <CABHktDW87XUgk1ZeO481Fnijh4B4EF6-zLmdwdufUm4q3tHzxQ@mail.gmail.com>
References: <DM2PR21MB00289E6687BBF27225FFCBA7AD210@DM2PR21MB0028.namprd21.prod.outlook.com>
 <CABHktDW87XUgk1ZeO481Fnijh4B4EF6-zLmdwdufUm4q3tHzxQ@mail.gmail.com>
Message-ID: <CABHktDVCaotnJ-hjcpX7StU4YeMF3_kPZjrfPgpOzvmaUCFtnA@mail.gmail.com>

That said, running the build on HEAD it seems that the template haskell
stuff committed today has broken the build again. I'd suggest checking out
the commit in my previous email which is just a few hours old. And cleaning
ghc-tarballs. As the error you seem to be getting is local.

On Thu, 9 Mar 2017, 16:38 Phyx, <lonetiger at gmail.com> wrote:

> Hi Simon,
>
> As of this morning the Windows build was working fine
> https://github.com/Mistuke/GhcWindowsBuild/commit/aa6906b2535224721d8b049cee3edcd938c3e951
> those are my nightly logs for last night at commit a02b80f
>
> That error seems to be coming from gcc and not ghc. We did update the crt
> and maybe the scripts didn't do the right thing. Could you try nuking
> ghc-tarballs and trying again? Of course running with -
> -enable-tarballs-autodownloads on.
>
> Tamar
>
> On Thu, 9 Mar 2017, 16:28 Simon Peyton Jones via ghc-devs, <
> ghc-devs at haskell.org> wrote:
>
> My windows build is more broken than usual.  I can’t even build a GHC.
>
> Please, could someone fix this?  I’m getting desperate.
>
> Simon
>
>
>
> libtool: compile:  C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H
> -I. -I.. -I. -I../include -Iinclude -I../src -Wall -Werror
> -fno-stack-protector -w -fexceptions -MT src/x86/ffi64.lo -MMD -MP -MF
> src/x86/.deps/ffi64.Tpo -c ../src/x86/ffi64.c -o src/x86/ffi64.o
>
> depbase=`echo src/x86/unix64.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
>
> /bin/sh ./libtool    --mode=compile C:/code/HEAD/inplace/mingw/bin/gcc.exe
> -DHAVE_CONFIG_H -I. -I..  -I. -I../include -Iinclude -I../src  -I.
> -I../include -Iinclude -I../src -Wall -Werror -fno-stack-protector -w -MT
> src/x86/unix64.lo -MMD -MP -MF $depbase.Tpo -c -o src/x86/unix64.lo
> ../src/x86/unix64.S &&\
>
> mv -f $depbase.Tpo $depbase.Plo
>
> libtool: compile:  C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H
> -I. -I.. -I. -I../include -Iinclude -I../src -I. -I../include -Iinclude
> -I../src -Wall -Werror -fno-stack-protector -w -MT src/x86/unix64.lo -MMD
> -MP -MF src/x86/.deps/unix64.Tpo -c ../src/x86/unix64.S -o src/x86/unix64.o
>
> ../src/x86/unix64.S: Assembler messages:
>
> ../src/x86/unix64.S:45: Error: junk at end of line, first unrecognized
> character is `f'
>
> ../src/x86/unix64.S:204: Error: junk at end of line, first unrecognized
> character is `f'
>
> ../src/x86/unix64.S:208: Error: junk at end of line, first unrecognized
> character is `f'
>
> ../src/x86/unix64.S:326: Error: junk at end of line, first unrecognized
> character is `f'
>
> ../src/x86/unix64.S:334: Error: junk at end of line, first unrecognized
> character is `,'
>
> make[5]: *** [Makefile:1335: src/x86/unix64.lo] Error 1
>
> make[5]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'
>
> make[4]: *** [Makefile:1596: all-recursive] Error 1
>
> make[4]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'
>
> make[3]: *** [Makefile:730: all] Error 2
>
> make[3]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'
>
> make[2]: *** [Makefile:608: all-all] Error 2
>
> rts/ghc.mk:494:
> rts/dist/build/.depend-v-l-debug-thr-thr_debug-thr_l.c_asm: No such file or
> directory
>
> make[1]: *** [libffi/ghc.mk:115: libffi/stamp.ffi.static.build] Error 2
>
> make: *** [Makefile:127: all] Error 2
>
> /c/code/HEAD$
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/8857917b/attachment.html>

From mail at joachim-breitner.de  Thu Mar  9 17:17:20 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 09 Mar 2017 18:17:20 +0100
Subject: Travis again over time
In-Reply-To: <1488893957.3556.4.camel@joachim-breitner.de>
References: <1488657386.11972.3.camel@joachim-breitner.de>
 <1488728220.8321.0.camel@joachim-breitner.de>
 <1488893957.3556.4.camel@joachim-breitner.de>
Message-ID: <1489079840.12255.1.camel@joachim-breitner.de>

Hi,

Am Dienstag, den 07.03.2017, 14:39 +0100 schrieb Joachim Breitner:
> The build would be marked as passing if it were not for
> integerConstantFolding which is marked as …

fixed this issue. Travis should pass now again. Let’s keep it this way!

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/023a8e88/attachment-0001.sig>

From lonetiger at gmail.com  Thu Mar  9 17:20:54 2017
From: lonetiger at gmail.com (Phyx)
Date: Thu, 09 Mar 2017 17:20:54 +0000
Subject: Windows build failing in a new way
In-Reply-To: <CABHktDVCaotnJ-hjcpX7StU4YeMF3_kPZjrfPgpOzvmaUCFtnA@mail.gmail.com>
References: <DM2PR21MB00289E6687BBF27225FFCBA7AD210@DM2PR21MB0028.namprd21.prod.outlook.com>
 <CABHktDW87XUgk1ZeO481Fnijh4B4EF6-zLmdwdufUm4q3tHzxQ@mail.gmail.com>
 <CABHktDVCaotnJ-hjcpX7StU4YeMF3_kPZjrfPgpOzvmaUCFtnA@mail.gmail.com>
Message-ID: <CABHktDVAxX3c4ZO=a15ieg6n4HTv+0SqYxMDy+sQi=RJVMVEqw@mail.gmail.com>

Checking again, I think something else is wrong I'll have to check later.
Sorry, but that commit above is still good. If you are really stuck use
that one.

Tamar

On Thu, 9 Mar 2017, 17:11 Phyx, <lonetiger at gmail.com> wrote:

> That said, running the build on HEAD it seems that the template haskell
> stuff committed today has broken the build again. I'd suggest checking out
> the commit in my previous email which is just a few hours old. And cleaning
> ghc-tarballs. As the error you seem to be getting is local.
>
> On Thu, 9 Mar 2017, 16:38 Phyx, <lonetiger at gmail.com> wrote:
>
> Hi Simon,
>
> As of this morning the Windows build was working fine
> https://github.com/Mistuke/GhcWindowsBuild/commit/aa6906b2535224721d8b049cee3edcd938c3e951
> those are my nightly logs for last night at commit a02b80f
>
> That error seems to be coming from gcc and not ghc. We did update the crt
> and maybe the scripts didn't do the right thing. Could you try nuking
> ghc-tarballs and trying again? Of course running with -
> -enable-tarballs-autodownloads on.
>
> Tamar
>
> On Thu, 9 Mar 2017, 16:28 Simon Peyton Jones via ghc-devs, <
> ghc-devs at haskell.org> wrote:
>
> My windows build is more broken than usual.  I can’t even build a GHC.
>
> Please, could someone fix this?  I’m getting desperate.
>
> Simon
>
>
>
> libtool: compile:  C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H
> -I. -I.. -I. -I../include -Iinclude -I../src -Wall -Werror
> -fno-stack-protector -w -fexceptions -MT src/x86/ffi64.lo -MMD -MP -MF
> src/x86/.deps/ffi64.Tpo -c ../src/x86/ffi64.c -o src/x86/ffi64.o
>
> depbase=`echo src/x86/unix64.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
>
> /bin/sh ./libtool    --mode=compile C:/code/HEAD/inplace/mingw/bin/gcc.exe
> -DHAVE_CONFIG_H -I. -I..  -I. -I../include -Iinclude -I../src  -I.
> -I../include -Iinclude -I../src -Wall -Werror -fno-stack-protector -w -MT
> src/x86/unix64.lo -MMD -MP -MF $depbase.Tpo -c -o src/x86/unix64.lo
> ../src/x86/unix64.S &&\
>
> mv -f $depbase.Tpo $depbase.Plo
>
> libtool: compile:  C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H
> -I. -I.. -I. -I../include -Iinclude -I../src -I. -I../include -Iinclude
> -I../src -Wall -Werror -fno-stack-protector -w -MT src/x86/unix64.lo -MMD
> -MP -MF src/x86/.deps/unix64.Tpo -c ../src/x86/unix64.S -o src/x86/unix64.o
>
> ../src/x86/unix64.S: Assembler messages:
>
> ../src/x86/unix64.S:45: Error: junk at end of line, first unrecognized
> character is `f'
>
> ../src/x86/unix64.S:204: Error: junk at end of line, first unrecognized
> character is `f'
>
> ../src/x86/unix64.S:208: Error: junk at end of line, first unrecognized
> character is `f'
>
> ../src/x86/unix64.S:326: Error: junk at end of line, first unrecognized
> character is `f'
>
> ../src/x86/unix64.S:334: Error: junk at end of line, first unrecognized
> character is `,'
>
> make[5]: *** [Makefile:1335: src/x86/unix64.lo] Error 1
>
> make[5]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'
>
> make[4]: *** [Makefile:1596: all-recursive] Error 1
>
> make[4]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'
>
> make[3]: *** [Makefile:730: all] Error 2
>
> make[3]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'
>
> make[2]: *** [Makefile:608: all-all] Error 2
>
> rts/ghc.mk:494:
> rts/dist/build/.depend-v-l-debug-thr-thr_debug-thr_l.c_asm: No such file or
> directory
>
> make[1]: *** [libffi/ghc.mk:115: libffi/stamp.ffi.static.build] Error 2
>
> make: *** [Makefile:127: all] Error 2
>
> /c/code/HEAD$
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/ce5171b3/attachment.html>

From ben at smart-cactus.org  Thu Mar  9 17:36:22 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 09 Mar 2017 12:36:22 -0500
Subject: Windows build failing in a new way
In-Reply-To: <DM2PR21MB00289E6687BBF27225FFCBA7AD210@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <DM2PR21MB00289E6687BBF27225FFCBA7AD210@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <87pohqnyi1.fsf@ben-laptop.smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> My windows build is more broken than usual.  I can't even build a GHC.
> Please, could someone fix this?  I'm getting desperate.

This is very odd; Harbormaster is also seeing it but I've been unable to
reproduce locally. It seems that the libffi build is failing but it's
quite unclear why it would fail for you yet succeed for me. I'll try to
reproduce on the Harbormaster machine.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/a7a2660c/attachment.sig>

From lonetiger at gmail.com  Thu Mar  9 17:43:58 2017
From: lonetiger at gmail.com (Phyx)
Date: Thu, 09 Mar 2017 17:43:58 +0000
Subject: Windows build failing in a new way
In-Reply-To: <87pohqnyi1.fsf@ben-laptop.smart-cactus.org>
References: <DM2PR21MB00289E6687BBF27225FFCBA7AD210@DM2PR21MB0028.namprd21.prod.outlook.com>
 <87pohqnyi1.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CABHktDUS60zKhfew6F0SFchAZPoWswYM1c0JKMTbc0DMpZXgCw@mail.gmail.com>

My CI server is also reproducing it while I also haven't been able to
locally. Weird indeed.

On Thu, 9 Mar 2017, 17:36 Ben Gamari, <ben at smart-cactus.org> wrote:

> Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:
>
> > My windows build is more broken than usual.  I can't even build a GHC.
> > Please, could someone fix this?  I'm getting desperate.
>
> This is very odd; Harbormaster is also seeing it but I've been unable to
> reproduce locally. It seems that the libffi build is failing but it's
> quite unclear why it would fail for you yet succeed for me. I'll try to
> reproduce on the Harbormaster machine.
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/9b8f7108/attachment.html>

From ben at smart-cactus.org  Thu Mar  9 18:51:21 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 09 Mar 2017 13:51:21 -0500
Subject: Windows build failing in a new way
In-Reply-To: <CABHktDUS60zKhfew6F0SFchAZPoWswYM1c0JKMTbc0DMpZXgCw@mail.gmail.com>
References: <DM2PR21MB00289E6687BBF27225FFCBA7AD210@DM2PR21MB0028.namprd21.prod.outlook.com>
 <87pohqnyi1.fsf@ben-laptop.smart-cactus.org>
 <CABHktDUS60zKhfew6F0SFchAZPoWswYM1c0JKMTbc0DMpZXgCw@mail.gmail.com>
Message-ID: <87h932nv12.fsf@ben-laptop.smart-cactus.org>

Phyx <lonetiger at gmail.com> writes:

> My CI server is also reproducing it while I also haven't been able to
> locally. Weird indeed.
>
Ahhh, I just noticed that Reid stumbled upon the culprit yesterday. See
[1].

Cheers,

- Ben


[1] https://phabricator.haskell.org/rGHCe901ed1c5d66
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/ef6ef17b/attachment.sig>

From lonetiger at gmail.com  Thu Mar  9 19:05:04 2017
From: lonetiger at gmail.com (lonetiger at gmail.com)
Date: Thu, 9 Mar 2017 19:05:04 +0000
Subject: Windows build failing in a new way
In-Reply-To: <87h932nv12.fsf@ben-laptop.smart-cactus.org>
References: <DM2PR21MB00289E6687BBF27225FFCBA7AD210@DM2PR21MB0028.namprd21.prod.outlook.com>
 <87pohqnyi1.fsf@ben-laptop.smart-cactus.org>
 <CABHktDUS60zKhfew6F0SFchAZPoWswYM1c0JKMTbc0DMpZXgCw@mail.gmail.com>
 <87h932nv12.fsf@ben-laptop.smart-cactus.org>
Message-ID: <58c1a760.4c0b1c0a.9d453.a800@mx.google.com>

Ah great,

Triples again.. I still wonder why it is suddenly an issue. We haven’t touched the .m4 file in a while and no one changed libffi either right? This is just like last time the normalization bit us. Causing days of broken builds on different targets while everyone fixed the one they were interested in.

Why do we do the normalization? It doesn’t seem to give us any benefits at all.. Maybe we should stop doing it after the branch for 8.4?

From: Ben Gamari
Sent: Thursday, March 9, 2017 18:51
To: Phyx; Simon Peyton Jones; ghc-devs at haskell.org
Subject: Re: Windows build failing in a new way

Phyx <lonetiger at gmail.com> writes:

> My CI server is also reproducing it while I also haven't been able to
> locally. Weird indeed.
>
Ahhh, I just noticed that Reid stumbled upon the culprit yesterday. See
[1].

Cheers,

- Ben


[1] https://phabricator.haskell.org/rGHCe901ed1c5d66

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/f0e59b36/attachment-0001.html>

From ekmett at gmail.com  Thu Mar  9 19:30:20 2017
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 9 Mar 2017 14:30:20 -0500
Subject: LLVM calling convention for AVX2 and AVX512 registers
Message-ID: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>

Back around 2013, Geoff raised a discussion about fixing up the GHC ABI so
that the LLVM calling convention could pass 256 bit vector types in YMM
(and, i suppose now 512 bit vector types in ZMM).

As I recall, this was blocked by some short term concerns about which LLVM
release was imminent or what have you. Four years on, the exact same sort
of arguments could be dredged up, but yet in the meantime nobody is really
using those types for anything.

This still creates a pain point around trying to use these wide types
today. Spilling rather than passing them in registers adds a LOT of
overhead to any attempt to use them that virtually erases any benefit to
having them in the first place.

I started experimenting with writing some custom primops directly in llvm
so I could do meaningful amounts of work with our SIMD vector types by just
banging out the code that we can't write in haskell directly using llvm
assembly, and hoping I could trick LLVM to do link time optimization to
perhaps inline it, but I'm basically dead in the water over the overhead of
our current calling convention, before I even start, it seems, as if we're
spilling them there is no way that inlining / LTO could hope to figure out
what we're doing out as part of the spill to erase that call entirely.

It is rather frustrating that I can't even cheat. =/

What do we need to do to finally fix this?

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/29629203/attachment.html>

From ben at smart-cactus.org  Thu Mar  9 19:38:46 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 09 Mar 2017 14:38:46 -0500
Subject: Windows build failing in a new way
In-Reply-To: <58c1a760.4c0b1c0a.9d453.a800@mx.google.com>
References: <DM2PR21MB00289E6687BBF27225FFCBA7AD210@DM2PR21MB0028.namprd21.prod.outlook.com>
 <87pohqnyi1.fsf@ben-laptop.smart-cactus.org>
 <CABHktDUS60zKhfew6F0SFchAZPoWswYM1c0JKMTbc0DMpZXgCw@mail.gmail.com>
 <87h932nv12.fsf@ben-laptop.smart-cactus.org>
 <58c1a760.4c0b1c0a.9d453.a800@mx.google.com>
Message-ID: <87efy6nsu1.fsf@ben-laptop.smart-cactus.org>

lonetiger at gmail.com writes:

> Ah great,
>
> Triples again.. I still wonder why it is suddenly an issue. We haven’t
> touched the .m4 file in a while and no one changed libffi either
> right? This is just like last time the normalization bit us. Causing
> days of broken builds on different targets while everyone fixed the
> one they were interested in.
>
Well, the patch that Reid points out indeed does change the triple which
we pass to subproject configures. However, I have been utterly unable to
reproduce this locally nor on the Harbormaster machine (both with
./validate).

Nevertheless, I have a hypothesis for the cause and a proposed fix in
D3304.

> Why do we do the normalization? It doesn’t seem to give us any
> benefits at all.. Maybe we should stop doing it after the branch for
> 8.4?
>
Well, there are a few different normalizations which you might mean
here. The patch in question affects autoconf's canonicalization. The
patch in question actually removes what may be the last reference to the
autoconf-canonicalized triple. However, my proposed fix then
reintroduces the need for it, since I suspect the cause is that we are
passing an empty triple to subproject configures.

There is also the matter of GHC's own triple normalization (e.g.
GHC_CONVERT_OS and friends, defined in aclocal.m4). I'm frankly not
entirely sure this is doing much harm and replacing it with autoconf's
canonicalized triple would be a non-trivial amount of work. However, if
you want to try I wouldn't be opposed.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/e5ec8b77/attachment.sig>

From mainland at apeiron.net  Thu Mar  9 20:11:39 2017
From: mainland at apeiron.net (Geoffrey Mainland)
Date: Thu, 9 Mar 2017 15:11:39 -0500
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
Message-ID: <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>

We would need to get a patch to LLVM accepted to change the GHC calling
convention.

Now that we commit to a particular version of LLVM, this might be less
of an issue than it once was since we wouldn't have to support versions
of LLVM that didn't support the new calling convention.

So...how do we get a patch into LLVM? I believe I once had such a patch
ready to go...I will dig around for it, but the change is very small and
easily recreated.

It would be even better if we could *also* teach the native back end
about SSE instructions. Is there anyone who might be willing to work on
that?

Geoff

On 3/9/17 2:30 PM, Edward Kmett wrote:
> Back around 2013, Geoff raised a discussion about fixing up the GHC
> ABI so that the LLVM calling convention could pass 256 bit vector
> types in YMM (and, i suppose now 512 bit vector types in ZMM).
>
> As I recall, this was blocked by some short term concerns about which
> LLVM release was imminent or what have you. Four years on, the exact
> same sort of arguments could be dredged up, but yet in the meantime
> nobody is really using those types for anything.
>
> This still creates a pain point around trying to use these wide types
> today. Spilling rather than passing them in registers adds a LOT of
> overhead to any attempt to use them that virtually erases any benefit
> to having them in the first place.
>
> I started experimenting with writing some custom primops directly in
> llvm so I could do meaningful amounts of work with our SIMD vector
> types by just banging out the code that we can't write in haskell
> directly using llvm assembly, and hoping I could trick LLVM to do link
> time optimization to perhaps inline it, but I'm basically dead in the
> water over the overhead of our current calling convention, before I
> even start, it seems, as if we're spilling them there is no way that
> inlining / LTO could hope to figure out what we're doing out as part
> of the spill to erase that call entirely.
>
> It is rather frustrating that I can't even cheat. =/
>
> What do we need to do to finally fix this?
>
> -Edward


From carter.schonwald at gmail.com  Thu Mar  9 20:31:45 2017
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 9 Mar 2017 15:31:45 -0500
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
Message-ID: <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>

the patch is still on TRAC,

https://ghc.haskell.org/trac/ghc/ticket/8033

we need to do changes to both the 32bit and 64bit ABIs, and I think thats
where I got stalled from lack of feedback

that aside:

heres the original email thread on the llvm commits thread
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20130708/180264.html

and theres links from there to the iterating on the test suite plus the
original patch

i'm more than happy to take a weekend to do the leg work, it was pretty fun
last time.

BUT, we need to agree on what ABI to do, and make sure that those ABI
changes dont create a performance regression for some unexpected reason.

On Thu, Mar 9, 2017 at 3:11 PM, Geoffrey Mainland <mainland at apeiron.net>
wrote:

> We would need to get a patch to LLVM accepted to change the GHC calling
> convention.
>
> Now that we commit to a particular version of LLVM, this might be less
> of an issue than it once was since we wouldn't have to support versions
> of LLVM that didn't support the new calling convention.
>
> So...how do we get a patch into LLVM? I believe I once had such a patch
> ready to go...I will dig around for it, but the change is very small and
> easily recreated.
>
> It would be even better if we could *also* teach the native back end
> about SSE instructions. Is there anyone who might be willing to work on
> that?
>
> Geoff
>
> On 3/9/17 2:30 PM, Edward Kmett wrote:
> > Back around 2013, Geoff raised a discussion about fixing up the GHC
> > ABI so that the LLVM calling convention could pass 256 bit vector
> > types in YMM (and, i suppose now 512 bit vector types in ZMM).
> >
> > As I recall, this was blocked by some short term concerns about which
> > LLVM release was imminent or what have you. Four years on, the exact
> > same sort of arguments could be dredged up, but yet in the meantime
> > nobody is really using those types for anything.
> >
> > This still creates a pain point around trying to use these wide types
> > today. Spilling rather than passing them in registers adds a LOT of
> > overhead to any attempt to use them that virtually erases any benefit
> > to having them in the first place.
> >
> > I started experimenting with writing some custom primops directly in
> > llvm so I could do meaningful amounts of work with our SIMD vector
> > types by just banging out the code that we can't write in haskell
> > directly using llvm assembly, and hoping I could trick LLVM to do link
> > time optimization to perhaps inline it, but I'm basically dead in the
> > water over the overhead of our current calling convention, before I
> > even start, it seems, as if we're spilling them there is no way that
> > inlining / LTO could hope to figure out what we're doing out as part
> > of the spill to erase that call entirely.
> >
> > It is rather frustrating that I can't even cheat. =/
> >
> > What do we need to do to finally fix this?
> >
> > -Edward
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/681ce9f6/attachment.html>

From carter.schonwald at gmail.com  Thu Mar  9 20:55:06 2017
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Thu, 9 Mar 2017 15:55:06 -0500
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
Message-ID: <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>

zooming out:

what *should* the new ABI be?

Ed was suggesting we make all 16 xmm/ymm/ lower 16 zmm registers (depending
on how they're being used) caller save,

(what about all 32 zmm registers? would they be float only, or also for
ints/words? simd has lots of nice int support!)

a) if this doesn't cause any perf regressions i've no objections

b) currently we only support passing floats/doubles and simd vectors of ,
do we wanna support int/word data there too? (or are the GPR / general
purpose registers enough for those? )

c) other stuff i'm probably overlooking

d) lets do this!

On Thu, Mar 9, 2017 at 3:31 PM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> the patch is still on TRAC,
>
> https://ghc.haskell.org/trac/ghc/ticket/8033
>
> we need to do changes to both the 32bit and 64bit ABIs, and I think thats
> where I got stalled from lack of feedback
>
> that aside:
>
> heres the original email thread on the llvm commits thread
> http://lists.llvm.org/pipermail/llvm-commits/Week-
> of-Mon-20130708/180264.html
>
> and theres links from there to the iterating on the test suite plus the
> original patch
>
> i'm more than happy to take a weekend to do the leg work, it was pretty
> fun last time.
>
> BUT, we need to agree on what ABI to do, and make sure that those ABI
> changes dont create a performance regression for some unexpected reason.
>
> On Thu, Mar 9, 2017 at 3:11 PM, Geoffrey Mainland <mainland at apeiron.net>
> wrote:
>
>> We would need to get a patch to LLVM accepted to change the GHC calling
>> convention.
>>
>> Now that we commit to a particular version of LLVM, this might be less
>> of an issue than it once was since we wouldn't have to support versions
>> of LLVM that didn't support the new calling convention.
>>
>> So...how do we get a patch into LLVM? I believe I once had such a patch
>> ready to go...I will dig around for it, but the change is very small and
>> easily recreated.
>>
>> It would be even better if we could *also* teach the native back end
>> about SSE instructions. Is there anyone who might be willing to work on
>> that?
>>
>> Geoff
>>
>> On 3/9/17 2:30 PM, Edward Kmett wrote:
>> > Back around 2013, Geoff raised a discussion about fixing up the GHC
>> > ABI so that the LLVM calling convention could pass 256 bit vector
>> > types in YMM (and, i suppose now 512 bit vector types in ZMM).
>> >
>> > As I recall, this was blocked by some short term concerns about which
>> > LLVM release was imminent or what have you. Four years on, the exact
>> > same sort of arguments could be dredged up, but yet in the meantime
>> > nobody is really using those types for anything.
>> >
>> > This still creates a pain point around trying to use these wide types
>> > today. Spilling rather than passing them in registers adds a LOT of
>> > overhead to any attempt to use them that virtually erases any benefit
>> > to having them in the first place.
>> >
>> > I started experimenting with writing some custom primops directly in
>> > llvm so I could do meaningful amounts of work with our SIMD vector
>> > types by just banging out the code that we can't write in haskell
>> > directly using llvm assembly, and hoping I could trick LLVM to do link
>> > time optimization to perhaps inline it, but I'm basically dead in the
>> > water over the overhead of our current calling convention, before I
>> > even start, it seems, as if we're spilling them there is no way that
>> > inlining / LTO could hope to figure out what we're doing out as part
>> > of the spill to erase that call entirely.
>> >
>> > It is rather frustrating that I can't even cheat. =/
>> >
>> > What do we need to do to finally fix this?
>> >
>> > -Edward
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/b69c1f62/attachment-0001.html>

From ben at smart-cactus.org  Thu Mar  9 21:18:55 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 09 Mar 2017 16:18:55 -0500
Subject: Windows build failing in a new way
In-Reply-To: <87efy6nsu1.fsf@ben-laptop.smart-cactus.org>
References: <DM2PR21MB00289E6687BBF27225FFCBA7AD210@DM2PR21MB0028.namprd21.prod.outlook.com>
 <87pohqnyi1.fsf@ben-laptop.smart-cactus.org>
 <CABHktDUS60zKhfew6F0SFchAZPoWswYM1c0JKMTbc0DMpZXgCw@mail.gmail.com>
 <87h932nv12.fsf@ben-laptop.smart-cactus.org>
 <58c1a760.4c0b1c0a.9d453.a800@mx.google.com>
 <87efy6nsu1.fsf@ben-laptop.smart-cactus.org>
Message-ID: <87a88uno74.fsf@ben-laptop.smart-cactus.org>

Ben Gamari <ben at smart-cactus.org> writes:

> lonetiger at gmail.com writes:
>
>> Ah great,
>>
>> Triples again.. I still wonder why it is suddenly an issue. We haven’t
>> touched the .m4 file in a while and no one changed libffi either
>> right? This is just like last time the normalization bit us. Causing
>> days of broken builds on different targets while everyone fixed the
>> one they were interested in.
>>
> Well, the patch that Reid points out indeed does change the triple which
> we pass to subproject configures. However, I have been utterly unable to
> reproduce this locally nor on the Harbormaster machine (both with
> ./validate).
>
> Nevertheless, I have a hypothesis for the cause and a proposed fix in
> D3304.
>
I believe at this point Harbormaster has demonstrated [1] that the fix
is effective. I'll go ahead and merge.

Cheers,

- Ben


[1] https://phabricator.haskell.org/harbormaster/build/23078/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/d40737d7/attachment.sig>

From ekmett at gmail.com  Fri Mar 10 03:00:42 2017
From: ekmett at gmail.com (Edward Kmett)
Date: Thu, 9 Mar 2017 22:00:42 -0500
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
Message-ID: <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>

If we only turn on ymm and zmm for passing explicit 256bit and 512bit
vector types then changing the ABI would have basically zero effect on any
code anybody is actually using today. Everything would remain abi
compatible unless it involves the new types that nobody is using.

This also has the benefit that turning on avx2 or avx512 wouldn't change
the calling convention of any code, making it much safer to link code
compiled with it on with code compiled with it off. That seems like a big
deal.

Moreover, if we start passing normal floats, etc. through them then our
lack of shuffles and ways to get data in/out of them becomes quite a pain
point.

As for passing int/word data, passing the vectors of them through the ymm
and zmm registers should be sufficient for the same reasons.

-Edward

On Thu, Mar 9, 2017 at 3:55 PM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> zooming out:
>
> what *should* the new ABI be?
>
> Ed was suggesting we make all 16 xmm/ymm/ lower 16 zmm registers
> (depending on how they're being used) caller save,
>
> (what about all 32 zmm registers? would they be float only, or also for
> ints/words? simd has lots of nice int support!)
>
> a) if this doesn't cause any perf regressions i've no objections
>
> b) currently we only support passing floats/doubles and simd vectors of ,
> do we wanna support int/word data there too? (or are the GPR / general
> purpose registers enough for those? )
>
> c) other stuff i'm probably overlooking
>
> d) lets do this!
>
> On Thu, Mar 9, 2017 at 3:31 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> the patch is still on TRAC,
>>
>> https://ghc.haskell.org/trac/ghc/ticket/8033
>>
>> we need to do changes to both the 32bit and 64bit ABIs, and I think thats
>> where I got stalled from lack of feedback
>>
>> that aside:
>>
>> heres the original email thread on the llvm commits thread
>> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-
>> 20130708/180264.html
>>
>> and theres links from there to the iterating on the test suite plus the
>> original patch
>>
>> i'm more than happy to take a weekend to do the leg work, it was pretty
>> fun last time.
>>
>> BUT, we need to agree on what ABI to do, and make sure that those ABI
>> changes dont create a performance regression for some unexpected reason.
>>
>> On Thu, Mar 9, 2017 at 3:11 PM, Geoffrey Mainland <mainland at apeiron.net>
>> wrote:
>>
>>> We would need to get a patch to LLVM accepted to change the GHC calling
>>> convention.
>>>
>>> Now that we commit to a particular version of LLVM, this might be less
>>> of an issue than it once was since we wouldn't have to support versions
>>> of LLVM that didn't support the new calling convention.
>>>
>>> So...how do we get a patch into LLVM? I believe I once had such a patch
>>> ready to go...I will dig around for it, but the change is very small and
>>> easily recreated.
>>>
>>> It would be even better if we could *also* teach the native back end
>>> about SSE instructions. Is there anyone who might be willing to work on
>>> that?
>>>
>>> Geoff
>>>
>>> On 3/9/17 2:30 PM, Edward Kmett wrote:
>>> > Back around 2013, Geoff raised a discussion about fixing up the GHC
>>> > ABI so that the LLVM calling convention could pass 256 bit vector
>>> > types in YMM (and, i suppose now 512 bit vector types in ZMM).
>>> >
>>> > As I recall, this was blocked by some short term concerns about which
>>> > LLVM release was imminent or what have you. Four years on, the exact
>>> > same sort of arguments could be dredged up, but yet in the meantime
>>> > nobody is really using those types for anything.
>>> >
>>> > This still creates a pain point around trying to use these wide types
>>> > today. Spilling rather than passing them in registers adds a LOT of
>>> > overhead to any attempt to use them that virtually erases any benefit
>>> > to having them in the first place.
>>> >
>>> > I started experimenting with writing some custom primops directly in
>>> > llvm so I could do meaningful amounts of work with our SIMD vector
>>> > types by just banging out the code that we can't write in haskell
>>> > directly using llvm assembly, and hoping I could trick LLVM to do link
>>> > time optimization to perhaps inline it, but I'm basically dead in the
>>> > water over the overhead of our current calling convention, before I
>>> > even start, it seems, as if we're spilling them there is no way that
>>> > inlining / LTO could hope to figure out what we're doing out as part
>>> > of the spill to erase that call entirely.
>>> >
>>> > It is rather frustrating that I can't even cheat. =/
>>> >
>>> > What do we need to do to finally fix this?
>>> >
>>> > -Edward
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/79ad7377/attachment.html>

From siddhanathan+eml at gmail.com  Fri Mar 10 05:49:59 2017
From: siddhanathan+eml at gmail.com (Siddhanathan Shanmugam)
Date: Thu, 9 Mar 2017 21:49:59 -0800
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
Message-ID: <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>

> It would be even better if we could *also* teach the native back end about
SSE instructions. Is there anyone who might be willing to work on that?

Yes. Though, it would be better if someone with more experience than me
decides to pick this up instead.

On Thu, Mar 9, 2017 at 7:00 PM, Edward Kmett <ekmett at gmail.com> wrote:

> If we only turn on ymm and zmm for passing explicit 256bit and 512bit
> vector types then changing the ABI would have basically zero effect on any
> code anybody is actually using today. Everything would remain abi
> compatible unless it involves the new types that nobody is using.
>
> This also has the benefit that turning on avx2 or avx512 wouldn't change
> the calling convention of any code, making it much safer to link code
> compiled with it on with code compiled with it off. That seems like a big
> deal.
>
> Moreover, if we start passing normal floats, etc. through them then our
> lack of shuffles and ways to get data in/out of them becomes quite a pain
> point.
>
> As for passing int/word data, passing the vectors of them through the ymm
> and zmm registers should be sufficient for the same reasons.
>
> -Edward
>
> On Thu, Mar 9, 2017 at 3:55 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> zooming out:
>>
>> what *should* the new ABI be?
>>
>> Ed was suggesting we make all 16 xmm/ymm/ lower 16 zmm registers
>> (depending on how they're being used) caller save,
>>
>> (what about all 32 zmm registers? would they be float only, or also for
>> ints/words? simd has lots of nice int support!)
>>
>> a) if this doesn't cause any perf regressions i've no objections
>>
>> b) currently we only support passing floats/doubles and simd vectors of ,
>> do we wanna support int/word data there too? (or are the GPR / general
>> purpose registers enough for those? )
>>
>> c) other stuff i'm probably overlooking
>>
>> d) lets do this!
>>
>> On Thu, Mar 9, 2017 at 3:31 PM, Carter Schonwald <
>> carter.schonwald at gmail.com> wrote:
>>
>>> the patch is still on TRAC,
>>>
>>> https://ghc.haskell.org/trac/ghc/ticket/8033
>>>
>>> we need to do changes to both the 32bit and 64bit ABIs, and I think
>>> thats where I got stalled from lack of feedback
>>>
>>> that aside:
>>>
>>> heres the original email thread on the llvm commits thread
>>> http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-201
>>> 30708/180264.html
>>>
>>> and theres links from there to the iterating on the test suite plus the
>>> original patch
>>>
>>> i'm more than happy to take a weekend to do the leg work, it was pretty
>>> fun last time.
>>>
>>> BUT, we need to agree on what ABI to do, and make sure that those ABI
>>> changes dont create a performance regression for some unexpected reason.
>>>
>>> On Thu, Mar 9, 2017 at 3:11 PM, Geoffrey Mainland <mainland at apeiron.net>
>>> wrote:
>>>
>>>> We would need to get a patch to LLVM accepted to change the GHC calling
>>>> convention.
>>>>
>>>> Now that we commit to a particular version of LLVM, this might be less
>>>> of an issue than it once was since we wouldn't have to support versions
>>>> of LLVM that didn't support the new calling convention.
>>>>
>>>> So...how do we get a patch into LLVM? I believe I once had such a patch
>>>> ready to go...I will dig around for it, but the change is very small and
>>>> easily recreated.
>>>>
>>>> It would be even better if we could *also* teach the native back end
>>>> about SSE instructions. Is there anyone who might be willing to work on
>>>> that?
>>>>
>>>> Geoff
>>>>
>>>> On 3/9/17 2:30 PM, Edward Kmett wrote:
>>>> > Back around 2013, Geoff raised a discussion about fixing up the GHC
>>>> > ABI so that the LLVM calling convention could pass 256 bit vector
>>>> > types in YMM (and, i suppose now 512 bit vector types in ZMM).
>>>> >
>>>> > As I recall, this was blocked by some short term concerns about which
>>>> > LLVM release was imminent or what have you. Four years on, the exact
>>>> > same sort of arguments could be dredged up, but yet in the meantime
>>>> > nobody is really using those types for anything.
>>>> >
>>>> > This still creates a pain point around trying to use these wide types
>>>> > today. Spilling rather than passing them in registers adds a LOT of
>>>> > overhead to any attempt to use them that virtually erases any benefit
>>>> > to having them in the first place.
>>>> >
>>>> > I started experimenting with writing some custom primops directly in
>>>> > llvm so I could do meaningful amounts of work with our SIMD vector
>>>> > types by just banging out the code that we can't write in haskell
>>>> > directly using llvm assembly, and hoping I could trick LLVM to do link
>>>> > time optimization to perhaps inline it, but I'm basically dead in the
>>>> > water over the overhead of our current calling convention, before I
>>>> > even start, it seems, as if we're spilling them there is no way that
>>>> > inlining / LTO could hope to figure out what we're doing out as part
>>>> > of the spill to erase that call entirely.
>>>> >
>>>> > It is rather frustrating that I can't even cheat. =/
>>>> >
>>>> > What do we need to do to finally fix this?
>>>> >
>>>> > -Edward
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170309/608cd941/attachment-0001.html>

From simonpj at microsoft.com  Fri Mar 10 08:47:05 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 10 Mar 2017 08:47:05 +0000
Subject: Windows build failing in a new way
In-Reply-To: <CABHktDW87XUgk1ZeO481Fnijh4B4EF6-zLmdwdufUm4q3tHzxQ@mail.gmail.com>
References: <DM2PR21MB00289E6687BBF27225FFCBA7AD210@DM2PR21MB0028.namprd21.prod.outlook.com>
 <CABHktDW87XUgk1ZeO481Fnijh4B4EF6-zLmdwdufUm4q3tHzxQ@mail.gmail.com>
Message-ID: <DM2PR21MB0028E5DFD8BC3D44BB4CDB08AD200@DM2PR21MB0028.namprd21.prod.outlook.com>

Actually it asked me thus:

Error:

Needed msys2 tarballs are missing. You have a few options to get them,



  * run configure with the --enable-tarballs-autodownload option

So I did as requested and ran configure with that flag.  Success:

checking for path to top of build tree... C:/code/HEAD

configure: Checking for Windows toolchain tarballs...

######################################################################## 100.0%

configure: Extracting Windows toolchain from archives (may take a while)...

configure: In-tree MingW-w64 tree created

configure: Making in-tree perl tree

configure: In-tree perl tree created

checking whether the C compiler works... yes

checking for C compiler default output file name... a.exe

Then I validated from scratch

sh validate --fast

and got the error I reported.

I suppose I could delete ghc-tarballs and try again.  I’ll do that when I’m next connected.

In case it  helps, the lines in unix64.S that are being rejected are

      .type      ffi_call_unix64, at function

…

      .size    ffi_call_unix64,.-ffi_call_unix64

..

      .type     ffi_closure_unix64, at function

…

      .size ffi_closure_unix64,.-ffi_closure_unix64

…

      .section      .eh_frame,"a", at progbits

Simon

From: Phyx [mailto:lonetiger at gmail.com]
Sent: 09 March 2017 16:38
To: Simon Peyton Jones <simonpj at microsoft.com>; ghc-devs at haskell.org
Subject: Re: Windows build failing in a new way


Hi Simon,

As of this morning the Windows build was working fine https://github.com/Mistuke/GhcWindowsBuild/commit/aa6906b2535224721d8b049cee3edcd938c3e951 those are my nightly logs for last night at commit a02b80f

That error seems to be coming from gcc and not ghc. We did update the crt and maybe the scripts didn't do the right thing. Could you try nuking ghc-tarballs and trying again? Of course running with - -enable-tarballs-autodownloads on.

Tamar

On Thu, 9 Mar 2017, 16:28 Simon Peyton Jones via ghc-devs, <ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>> wrote:
My windows build is more broken than usual.  I can’t even build a GHC.
Please, could someone fix this?  I’m getting desperate.
Simon


libtool: compile:  C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -Wall -Werror -fno-stack-protector -w -fexceptions -MT src/x86/ffi64.lo -MMD -MP -MF src/x86/.deps/ffi64.Tpo -c ../src/x86/ffi64.c -o src/x86/ffi64.o

depbase=`echo src/x86/unix64.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\

/bin/sh ./libtool    --mode=compile C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H -I. -I..  -I. -I../include -Iinclude -I../src  -I. -I../include -Iinclude -I../src -Wall -Werror -fno-stack-protector -w -MT src/x86/unix64.lo -MMD -MP -MF $depbase.Tpo -c -o src/x86/unix64.lo ../src/x86/unix64.S &&\

mv -f $depbase.Tpo $depbase.Plo

libtool: compile:  C:/code/HEAD/inplace/mingw/bin/gcc.exe -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude -I../src -I. -I../include -Iinclude -I../src -Wall -Werror -fno-stack-protector -w -MT src/x86/unix64.lo -MMD -MP -MF src/x86/.deps/unix64.Tpo -c ../src/x86/unix64.S -o src/x86/unix64.o

../src/x86/unix64.S: Assembler messages:

../src/x86/unix64.S:45: Error: junk at end of line, first unrecognized character is `f'

../src/x86/unix64.S:204: Error: junk at end of line, first unrecognized character is `f'

../src/x86/unix64.S:208: Error: junk at end of line, first unrecognized character is `f'

../src/x86/unix64.S:326: Error: junk at end of line, first unrecognized character is `f'

../src/x86/unix64.S:334: Error: junk at end of line, first unrecognized character is `,'

make[5]: *** [Makefile:1335: src/x86/unix64.lo] Error 1

make[5]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'

make[4]: *** [Makefile:1596: all-recursive] Error 1

make[4]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'

make[3]: *** [Makefile:730: all] Error 2

make[3]: Leaving directory '/c/code/HEAD/libffi/build/x86_64-pc-msys'

make[2]: *** [Makefile:608: all-all] Error 2

rts/ghc.mk:494<http://ghc.mk:494>: rts/dist/build/.depend-v-l-debug-thr-thr_debug-thr_l.c_asm: No such file or directory

make[1]: *** [libffi/ghc.mk:115<http://ghc.mk:115>: libffi/stamp.ffi.static.build] Error 2

make: *** [Makefile:127: all] Error 2

/c/code/HEAD$
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170310/6e9516cb/attachment-0001.html>

From simonpj at microsoft.com  Fri Mar 10 13:15:00 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 10 Mar 2017 13:15:00 +0000
Subject: FW: GHC on Windows 10 15019+
In-Reply-To: <CALqZiMweJgus_JvZJ+XhoUEE6jXuVmfvB=oF-W_w5AUML0Uu9w@mail.gmail.com>
References: <CALqZiMweJgus_JvZJ+XhoUEE6jXuVmfvB=oF-W_w5AUML0Uu9w@mail.gmail.com>
Message-ID: <DM2PR21MB00281B4BF21032ECD310FA8AAD200@DM2PR21MB0028.namprd21.prod.outlook.com>

Phyx and friends: does this ring a bell?  Do we have a ticket?

-----Original Message-----
From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of J. Garrett Morris
Sent: 09 March 2017 17:54
To: GHC users <glasgow-haskell-users at haskell.org>
Subject: GHC on Windows 10 15019+

Hi y'all,

I've recently run into a problem using released version of GHC on Windows 10, builds 15019 and later.  The problem seems to be an incompatibility with Mingw64---builds fail calling realgcc.exe with vaguely incomprehensible error messages (Program failed to start with error 0xc0000142).

Replacing the packaged version of Mingw64 with a more recent build (from Msys2, say) restores functioning, but no longer works if there are spaces in the path to GHC.

I've observed this on three different machines, so I don't think it's just a configuration oddity.  Has anyone else encountered similar problems, or can anyone else verify?  If so, it might be worth repackaging at least the latest released version with a more recent Mingw64.

 /g

--
Prosperum ac felix scelus virtus vocatur
 -- Seneca

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

From lonetiger at gmail.com  Fri Mar 10 13:49:48 2017
From: lonetiger at gmail.com (Phyx)
Date: Fri, 10 Mar 2017 13:49:48 +0000
Subject: FW: GHC on Windows 10 15019+
In-Reply-To: <DM2PR21MB00281B4BF21032ECD310FA8AAD200@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <CALqZiMweJgus_JvZJ+XhoUEE6jXuVmfvB=oF-W_w5AUML0Uu9w@mail.gmail.com>
 <DM2PR21MB00281B4BF21032ECD310FA8AAD200@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <CABHktDXUN76cAgmoe1WubifL_-n8+Z+c4kCcCi4d0iX+O_W4rg@mail.gmail.com>

Hi Simon,

No it doesn't ring a bell to me, though I don't generally use the insider
builds. I think 0xc0000142 is a compatibility error, but what is not clear
to me is if he replaced realgcc which is a stub we make or just updated
things in the mingw folder. So I can't really tell if the error is coming
from our driver or gcc itself.

I'll have to install the build in a VM to try. Also as it stands 8.2 will
ship with an updated mingw-w64 tool chain already. It will be at 6.2.0-2 vs
very latest which is 6.3.0-3.

I'll see if I can reproduce and open a ticket accordingly.

Kind regards,
Tamar

On Fri, 10 Mar 2017, 13:15 Simon Peyton Jones via ghc-devs, <
ghc-devs at haskell.org> wrote:

> Phyx and friends: does this ring a bell?  Do we have a ticket?
>
> -----Original Message-----
> From: Glasgow-haskell-users [mailto:
> glasgow-haskell-users-bounces at haskell.org] On Behalf Of J. Garrett Morris
> Sent: 09 March 2017 17:54
> To: GHC users <glasgow-haskell-users at haskell.org>
> Subject: GHC on Windows 10 15019+
>
> Hi y'all,
>
> I've recently run into a problem using released version of GHC on Windows
> 10, builds 15019 and later.  The problem seems to be an incompatibility
> with Mingw64---builds fail calling realgcc.exe with vaguely
> incomprehensible error messages (Program failed to start with error
> 0xc0000142).
>
> Replacing the packaged version of Mingw64 with a more recent build (from
> Msys2, say) restores functioning, but no longer works if there are spaces
> in the path to GHC.
>
> I've observed this on three different machines, so I don't think it's just
> a configuration oddity.  Has anyone else encountered similar problems, or
> can anyone else verify?  If so, it might be worth repackaging at least the
> latest released version with a more recent Mingw64.
>
>  /g
>
> --
> Prosperum ac felix scelus virtus vocatur
>  -- Seneca
>
> The University of Edinburgh is a charitable body, registered in Scotland,
> with registration number SC005336.
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170310/31364d84/attachment.html>

From simonpj at microsoft.com  Fri Mar 10 16:11:42 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 10 Mar 2017 16:11:42 +0000
Subject: New commits
Message-ID: <DM2PR21MB00280EEAE68915A522CEBF41AD200@DM2PR21MB0028.namprd21.prod.outlook.com>

Edward, Ben, others
I have just pushed a patch series

2209d5e6 Comments only

4eeb3273 Drop redundant import

2d3cb34a Define TcSimplify.simplifyTopImplic and use it

af6ed4a6 Fix constraint simplification in rules

48d1866e Improve error messages for skolems

7e96526a Fix TcSimplify.decideQuantification for kind variables

bc0f3abd Deal with JoinIds before void types

900cfdc2 Do not generate a data-con wrapper for !Int#
Issues:

*         bkpcabal03 is failing... I don't see how it can possibly have anything to do with me, so I've pushed anyway.  Edward, might you look?

*         I get these stat failures - all improvements

   perf/compiler/T13035.run    T13035 [stat too good] (normal)

   perf/compiler/T12425.run    T12425 [stat too good] (optasm)

   perf/compiler/T9675.run     T9675 [stat too good] (optasm)

   perf/space_leaks/T4029.run  T4029 [stat too good] (ghci)

   perf/should_run/T10359.run  T10359 [stat too good] (normal)

   perf/compiler/T1969.run     T1969 [stat too good] (normal)

Some of them are from before (I reported this and suggested re-centreing the numbers), but the last two are new, I think.  Hurrah!   Ben: might you look?
Sorry for playing a bit fast and loose, but I'm out of time, and there are bug-fixes in here.
Thanks
Simon
bkpcabal03

simonpj at cam-05-unx:~/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03$ make bkpcabal03

rm -f -r tmp.d inst dist Setup

make -s --no-print-directory clean

'/5playpen/simonpj/HEAD-5/inplace/test   spaces/ghc-pkg' init tmp.d

'/5playpen/simonpj/HEAD-5/inplace/test   spaces/ghc-stage2' -v0 --make Setup

cp bkpcabal03.cabal.in1 bkpcabal03.cabal

# typecheck asig1

(cd asig1; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 configure --enable-library-vanilla --disable-shared --with-ghc='/5playpen/simonpj/HEAD-5/inplace/test   spaces/ghc-stage2' --ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts  -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output' --package-db='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/tmp.d' --prefix='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/inst' --cid "asig1" asig1)

(cd asig1; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 build)

(cd asig1; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 copy)

(cd asig1; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 register)

# typecheck asig2

(cd asig2; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 configure --enable-library-vanilla --disable-shared --with-ghc='/5playpen/simonpj/HEAD-5/inplace/test   spaces/ghc-stage2' --ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts  -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output' --package-db='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/tmp.d' --prefix='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/inst' --cid "asig2" asig2)

(cd asig2; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 build)

(cd asig2; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 copy)

(cd asig2; '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 register)

# typecheck top-level

'/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 configure --enable-library-vanilla --disable-shared --with-ghc='/5playpen/simonpj/HEAD-5/inplace/test   spaces/ghc-stage2' --ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts  -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output' --package-db='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/tmp.d' --prefix='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/inst' --cid "toplevel" bkpcabal03

! '/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 build



<no location info>: warning: [-Wmissing-home-modules]

    Modules are not listed in command line: Foo



Mod.hs:4:5: error: Variable not in scope: g :: Int

# modify mixins

cp bkpcabal03.cabal.in2 bkpcabal03.cabal

# retypecheck top-level

'/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 configure --enable-library-vanilla --disable-shared --with-ghc='/5playpen/simonpj/HEAD-5/inplace/test   spaces/ghc-stage2' --ghc-options='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts  -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output' --package-db='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/tmp.d' --prefix='/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/inst' --cid "toplevel" bkpcabal03

'/home/simonpj/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03/Setup' -v0 build



<no location info>: warning: [-Wmissing-home-modules]

    Modules are not listed in command line: Foo

simonpj at cam-05-unx:~/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03$ dirs

~/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03 ~/5builds/HEAD-5 ~/code/HEAD-5

simonpj at cam-05-unx:~/5builds/HEAD-5/testsuite/tests/backpack/cabal/bkpcabal03$

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170310/890a1b52/attachment-0001.html>

From simonpj at microsoft.com  Fri Mar 10 16:37:20 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 10 Mar 2017 16:37:20 +0000
Subject: Windows
Message-ID: <DM2PR21MB0028A2FA60323B8B596C455CAD200@DM2PR21MB0028.namprd21.prod.outlook.com>

Windows build is working again....thank you!
(To be fair, I'm still building stage2, so have not tried the testsuite yet, but I live in hope.)
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170310/deabaff3/attachment.html>

From ben at well-typed.com  Fri Mar 10 17:56:01 2017
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 10 Mar 2017 12:56:01 -0500
Subject: New commits
In-Reply-To: <DM2PR21MB00280EEAE68915A522CEBF41AD200@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <DM2PR21MB00280EEAE68915A522CEBF41AD200@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <87y3wdm2xa.fsf@ben-laptop.smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> Edward, Ben, others
> I have just pushed a patch series
>
> 2209d5e6 Comments only
>
> 4eeb3273 Drop redundant import
>
> 2d3cb34a Define TcSimplify.simplifyTopImplic and use it
>
> af6ed4a6 Fix constraint simplification in rules
>
> 48d1866e Improve error messages for skolems
>
> 7e96526a Fix TcSimplify.decideQuantification for kind variables
>
> bc0f3abd Deal with JoinIds before void types
>
> 900cfdc2 Do not generate a data-con wrapper for !Int#
> Issues:
>
> *         bkpcabal03 is failing... I don't see how it can possibly have anything to do with me, so I've pushed anyway.  Edward, might you look?
>
> *         I get these stat failures - all improvements
>
>    perf/compiler/T13035.run    T13035 [stat too good] (normal)
>
>    perf/compiler/T12425.run    T12425 [stat too good] (optasm)
>
>    perf/compiler/T9675.run     T9675 [stat too good] (optasm)
>
>    perf/space_leaks/T4029.run  T4029 [stat too good] (ghci)
>
>    perf/should_run/T10359.run  T10359 [stat too good] (normal)
>
>    perf/compiler/T1969.run     T1969 [stat too good] (normal)
>
> Some of them are from before (I reported this and suggested
> re-centreing the numbers), but the last two are new, I think. Hurrah!
> Ben: might you look?

Sure.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170310/ff2126d8/attachment.sig>

From david at well-typed.com  Fri Mar 10 22:17:47 2017
From: david at well-typed.com (David Feuer)
Date: Fri, 10 Mar 2017 17:17:47 -0500
Subject: What should and should not be marked has_side_effects?
Message-ID: <36334466.Z0lWzkfasP@squirrel>

Note [PrimOp can_fail and has_side_effects] in prelude/PrimOp.hs says

> A primop "has_side_effects" if it has some *write* effect, visible
> elsewhere
> 
>     - writing to the world (I/O)
>     - writing to a mutable data structure (writeIORef)
>     - throwing a synchronous Haskell exception
>
> [...]
>
>  * NB3: *Read* effects (like reading an IORef) don't count here,
>  
>    because it doesn't matter if we don't do them, or do them more than
>    once.  *Sequencing* is maintained by the data dependency of the state
>    token.

But this does not actually seem to match what goes on in primops.txt.pp. The 
following, among many other seemingly read-only operations, have  
has_side_effects = True:

readMutVar# (the very example cited!), readArray#, unsafeFreezeArray#, 
unsafeThawArray#, tryReadMVar#, deRefWeak#

So what's the correct story? Do we want to change the note, or change the 
reality? The reason I happen to be looking at this is that I think the current 
arrangement allows us to define unsafeInterleaveIO in a particularly simple 
fashion:

unsafeInterleaveIO = pure . unsafePerformIO

but that's only safe as long as the interleaved IO won't float out and get 
performed before it's forced by normal IO.

But the unsafeInterleaveIO story seems much less important, in the grand 
scheme of things, than making everything else run fast. If indeed it's 
otherwise safe to mark these read-only ops has_side_effects=False, then I 
imagine we probably should do that.

David Feuer

From carter.schonwald at gmail.com  Sat Mar 11 13:13:19 2017
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 11 Mar 2017 13:13:19 +0000
Subject: What should and should not be marked has_side_effects?
In-Reply-To: <36334466.Z0lWzkfasP@squirrel>
References: <36334466.Z0lWzkfasP@squirrel>
Message-ID: <CAHYVw0wRGc+_CQViPxi8a7QgigUnEuK6Ym9xj_-QpsVuroL0Pg@mail.gmail.com>

I know that in the case of the prefetch operations they need to be treated
like writes so that other operations don't get reordered before / after
them.

For Mvars, concurrency probably comes into play.  Or at least, before we
did a readMvar primop it was made out of a take and put, so even through
the read prim doesn't write and doesn't block other readers, we still want
to treat it's ordering as through it has a write like side effect (Edward
yang can probably better opine than I on that one )





On Fri, Mar 10, 2017 at 5:17 PM David Feuer <david at well-typed.com> wrote:

> Note [PrimOp can_fail and has_side_effects] in prelude/PrimOp.hs says
>
> > A primop "has_side_effects" if it has some *write* effect, visible
> > elsewhere
> >
> >     - writing to the world (I/O)
> >     - writing to a mutable data structure (writeIORef)
> >     - throwing a synchronous Haskell exception
> >
> > [...]
> >
> >  * NB3: *Read* effects (like reading an IORef) don't count here,
> >
> >    because it doesn't matter if we don't do them, or do them more than
> >    once.  *Sequencing* is maintained by the data dependency of the state
> >    token.
>
> But this does not actually seem to match what goes on in primops.txt.pp.
> The
> following, among many other seemingly read-only operations, have
> has_side_effects = True:
>
> readMutVar# (the very example cited!), readArray#, unsafeFreezeArray#,
> unsafeThawArray#, tryReadMVar#, deRefWeak#
>
> So what's the correct story? Do we want to change the note, or change the
> reality? The reason I happen to be looking at this is that I think the
> current
> arrangement allows us to define unsafeInterleaveIO in a particularly simple
> fashion:
>
> unsafeInterleaveIO = pure . unsafePerformIO
>
> but that's only safe as long as the interleaved IO won't float out and get
> performed before it's forced by normal IO.
>
> But the unsafeInterleaveIO story seems much less important, in the grand
> scheme of things, than making everything else run fast. If indeed it's
> otherwise safe to mark these read-only ops has_side_effects=False, then I
> imagine we probably should do that.
>
> David Feuer
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170311/808aca85/attachment.html>

From rae at cs.brynmawr.edu  Sun Mar 12 21:57:13 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sun, 12 Mar 2017 17:57:13 -0400
Subject: can't validate on Linux
Message-ID: <3491BAC5-ECB8-4C67-B35F-8EE8F8805F5A@cs.brynmawr.edu>

Hi devs,

When I try validating my patch, validation fails with

> ...
> Registering library for ghc-prim-0.5.0.0..
> ghc-cabal: '/home/rae/ghc/ghc-valid/bindisttest/install
> dir/lib/ghc-8.3.20170312/bin/ghc-pkg' exited with an error:
> ghc-pkg: Couldn't open database /home/rae/ghc/ghc-valid/bindisttest/install
> dir/lib/ghc-8.3.20170312/package.conf.d for modification: {handle:
> /home/rae/ghc/ghc-valid/bindisttest/install
> dir/lib/ghc-8.3.20170312/package.conf.d/package.cache.lock}: hLock: invalid
> argument (Bad file descriptor)
> make[3]: *** [ghc.mk:990: install_packages] Error 1
> make[2]: *** [Makefile:51: install] Error 2
> make[1]: *** [bindisttest/ghc.mk:33: test_bindist] Error 2
> make: *** [Makefile:127: test_bindist] Error 2

Any advice?

Thanks!
Richard

From mle+hs at mega-nerd.com  Mon Mar 13 07:35:33 2017
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Mon, 13 Mar 2017 18:35:33 +1100
Subject: can't validate on Linux
In-Reply-To: <3491BAC5-ECB8-4C67-B35F-8EE8F8805F5A@cs.brynmawr.edu>
References: <3491BAC5-ECB8-4C67-B35F-8EE8F8805F5A@cs.brynmawr.edu>
Message-ID: <20170313183533.860465cdf2b5260c2883ca59@mega-nerd.com>

Richard Eisenberg wrote:

> /home/rae/ghc/ghc-valid/bindisttest/install
> > dir/lib/ghc-8.3.20170312/package.conf.d/package.cache.lock

I'd try manually deleting that file.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From ben at smart-cactus.org  Mon Mar 13 14:07:38 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 13 Mar 2017 10:07:38 -0400
Subject: can't validate on Linux
In-Reply-To: <3491BAC5-ECB8-4C67-B35F-8EE8F8805F5A@cs.brynmawr.edu>
References: <3491BAC5-ECB8-4C67-B35F-8EE8F8805F5A@cs.brynmawr.edu>
Message-ID: <87r321mfrp.fsf@ben-laptop.smart-cactus.org>

Richard Eisenberg <rae at cs.brynmawr.edu> writes:

> Hi devs,
>
> When I try validating my patch, validation fails with
>
>> ...
>> Registering library for ghc-prim-0.5.0.0..
>> ghc-cabal: '/home/rae/ghc/ghc-valid/bindisttest/install
>> dir/lib/ghc-8.3.20170312/bin/ghc-pkg' exited with an error:
>> ghc-pkg: Couldn't open database /home/rae/ghc/ghc-valid/bindisttest/install
>> dir/lib/ghc-8.3.20170312/package.conf.d for modification: {handle:
>> /home/rae/ghc/ghc-valid/bindisttest/install
>> dir/lib/ghc-8.3.20170312/package.conf.d/package.cache.lock}: hLock: invalid
>> argument (Bad file descriptor)
>> make[3]: *** [ghc.mk:990: install_packages] Error 1
>> make[2]: *** [Makefile:51: install] Error 2
>> make[1]: *** [bindisttest/ghc.mk:33: test_bindist] Error 2
>> make: *** [Makefile:127: test_bindist] Error 2
>
This is when I typically `make distclean`. That being said, this does
look a bit suspicious. Let me know if cleaning doesn't help.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170313/6e56a5f1/attachment.sig>

From ben at well-typed.com  Mon Mar 13 18:38:39 2017
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 13 Mar 2017 14:38:39 -0400
Subject: Trac password change interface restored
Message-ID: <874lyxm380.fsf@ben-laptop.smart-cactus.org>

Hello everyone,

For the last few weeks Trac's password change functionality has been
disabled due to passwords being leaked through the ghc-tickets mailing
list.

I have updated the Trac configuration to fix this leakage and reenabled
this interface. Moreover, we shouldn't see any further email address
verifications messages on ghc-tickets.

Thanks to everyone for their patience while this was handled.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170313/9c32ca7a/attachment.sig>

From ben at well-typed.com  Mon Mar 13 18:44:58 2017
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 13 Mar 2017 14:44:58 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
Message-ID: <871su1m2xh.fsf@ben-laptop.smart-cactus.org>

Siddhanathan Shanmugam <siddhanathan+eml at gmail.com> writes:

>> It would be even better if we could *also* teach the native back end about
> SSE instructions. Is there anyone who might be willing to work on that?
>
> Yes. Though, it would be better if someone with more experience than me
> decides to pick this up instead.
>
I would be happy to advise if you would like to pick this up. I think it
would be great if the NCG were to learn about SSE and GHC could really
use more people knowledgable about its backend. The best way to learn is
by doing.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170313/82682ced/attachment.sig>

From rae at cs.brynmawr.edu  Mon Mar 13 20:32:00 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 13 Mar 2017 16:32:00 -0400
Subject: can't validate on Linux
In-Reply-To: <87r321mfrp.fsf@ben-laptop.smart-cactus.org>
References: <3491BAC5-ECB8-4C67-B35F-8EE8F8805F5A@cs.brynmawr.edu>
 <87r321mfrp.fsf@ben-laptop.smart-cactus.org>
Message-ID: <6DA25F5F-FED1-4F1D-977E-5DAF348369DF@cs.brynmawr.edu>

This was a fresh validation run, so make distclean won’t do it. And deleting the file makes no difference. For what it’s worth, I ran with CPUS=1 (instead of my usual CPUS=32) to avoid threading problems.

Any other suggestions?

Thanks!
Richard

> On Mar 13, 2017, at 10:07 AM, Ben Gamari <ben at smart-cactus.org> wrote:
> 
> Richard Eisenberg <rae at cs.brynmawr.edu> writes:
> 
>> Hi devs,
>> 
>> When I try validating my patch, validation fails with
>> 
>>> ...
>>> Registering library for ghc-prim-0.5.0.0..
>>> ghc-cabal: '/home/rae/ghc/ghc-valid/bindisttest/install
>>> dir/lib/ghc-8.3.20170312/bin/ghc-pkg' exited with an error:
>>> ghc-pkg: Couldn't open database /home/rae/ghc/ghc-valid/bindisttest/install
>>> dir/lib/ghc-8.3.20170312/package.conf.d for modification: {handle:
>>> /home/rae/ghc/ghc-valid/bindisttest/install
>>> dir/lib/ghc-8.3.20170312/package.conf.d/package.cache.lock}: hLock: invalid
>>> argument (Bad file descriptor)
>>> make[3]: *** [ghc.mk:990: install_packages] Error 1
>>> make[2]: *** [Makefile:51: install] Error 2
>>> make[1]: *** [bindisttest/ghc.mk:33: test_bindist] Error 2
>>> make: *** [Makefile:127: test_bindist] Error 2
>> 
> This is when I typically `make distclean`. That being said, this does
> look a bit suspicious. Let me know if cleaning doesn't help.
> 
> Cheers,
> 
> - Ben


From ben at well-typed.com  Mon Mar 13 21:57:45 2017
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 13 Mar 2017 17:57:45 -0400
Subject: can't validate on Linux
In-Reply-To: <3491BAC5-ECB8-4C67-B35F-8EE8F8805F5A@cs.brynmawr.edu>
References: <3491BAC5-ECB8-4C67-B35F-8EE8F8805F5A@cs.brynmawr.edu>
Message-ID: <87r320lu06.fsf@ben-laptop.smart-cactus.org>

Richard Eisenberg <rae at cs.brynmawr.edu> writes:

> Hi devs,
>
> When I try validating my patch, validation fails with
>
>> ...
>> Registering library for ghc-prim-0.5.0.0..
>> ghc-cabal: '/home/rae/ghc/ghc-valid/bindisttest/install
>> dir/lib/ghc-8.3.20170312/bin/ghc-pkg' exited with an error:
>> ghc-pkg: Couldn't open database /home/rae/ghc/ghc-valid/bindisttest/install
>> dir/lib/ghc-8.3.20170312/package.conf.d for modification: {handle:
>> /home/rae/ghc/ghc-valid/bindisttest/install
>> dir/lib/ghc-8.3.20170312/package.conf.d/package.cache.lock}: hLock: invalid
>> argument (Bad file descriptor)

Andrzej, it looks like this is another ghc-pkg issue. Do you have any
idea what is going on here?

Richard, this is on Linux, yes?

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170313/067cd8a1/attachment.sig>

From rae at cs.brynmawr.edu  Mon Mar 13 22:17:26 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 13 Mar 2017 18:17:26 -0400
Subject: can't validate on Linux
In-Reply-To: <87r320lu06.fsf@ben-laptop.smart-cactus.org>
References: <3491BAC5-ECB8-4C67-B35F-8EE8F8805F5A@cs.brynmawr.edu>
 <87r320lu06.fsf@ben-laptop.smart-cactus.org>
Message-ID: <7093FA1B-E20D-44E3-AA6E-CC307BA55924@cs.brynmawr.edu>


> On Mar 13, 2017, at 5:57 PM, Ben Gamari <ben at well-typed.com> wrote:
> 
> Richard, this is on Linux, yes?

Yes, it is. But I have now noticed other aspects of some very strange behavior regarding the filesystem on my Linux server, so the problem may be unrelated to GHC. (Example of other problem: running the testsuite, with `make`, reveals tons of stderr mismatches. Some digging reveals that the .run.stderr files are sometimes truncated.)

So, thanks for the offers for help, but I’ve passed this problem up to my sysadmin.

Thanks,
Richard

From ekmett at gmail.com  Mon Mar 13 22:39:29 2017
From: ekmett at gmail.com (Edward Kmett)
Date: Mon, 13 Mar 2017 18:39:29 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <871su1m2xh.fsf@ben-laptop.smart-cactus.org>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <871su1m2xh.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAJumaK8q4yC0Dh3Hm8je6DieLLPGEuftyyzt6tUrYacORgiTng@mail.gmail.com>

That, rather tangentially, reminds me: If we do start to teach the code
generator about how to produce these sorts of things from simpler parts,
e.g. via enabling something like LLVM's vectorization pass, or some
internal future ghc compiler pass that checks for, say, Superword-Level
Parallelism
<http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.4663&rep=rep1&type=pdf>
in the style of Jaewook Shin, then we need to differentiate between flags
for what ghc/llvm is allowed to produce via optimization, etc. and what the
end user is allowed to explicitly emit. e.g. in my own code I can safely
call avx2 primitives after I set up guards to check that I'm on a CPU that
supports them, but I can only currently emit that code after I tell GHC
that I want it to allow the avx2 instructions. If I build a complicated
dispatch mechanism in Haskell for picking the right ISA and emitting code
for several of them, I'm going to need to tell ghc to let me build with all
sorts of instruction sets that the machine the final executable runs on may
not fully support. We should be careful not to conflate these two things.

-Edward

On Mon, Mar 13, 2017 at 2:44 PM, Ben Gamari <ben at well-typed.com> wrote:

> Siddhanathan Shanmugam <siddhanathan+eml at gmail.com> writes:
>
> >> It would be even better if we could *also* teach the native back end
> about
> > SSE instructions. Is there anyone who might be willing to work on that?
> >
> > Yes. Though, it would be better if someone with more experience than me
> > decides to pick this up instead.
> >
> I would be happy to advise if you would like to pick this up. I think it
> would be great if the NCG were to learn about SSE and GHC could really
> use more people knowledgable about its backend. The best way to learn is
> by doing.
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170313/294ef23b/attachment.html>

From ben at well-typed.com  Mon Mar 13 22:57:19 2017
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 13 Mar 2017 18:57:19 -0400
Subject: Removing core-spec.pdf from repository?
Message-ID: <87o9x4lr8w.fsf@ben-laptop.smart-cactus.org>

Hello everyone,

Currently there is a typeset copy of the Core specification in the GHC
repository. This means any time someone changes the specification the
repository grows by around 300kB. While this isn't the end of the
world, it's generally considered bad form to put generated files under
version control.

Of course, the tools required to typeset the specification (ott and
LaTeX) are non-trivial to install, so there is considerable convenience
that comes from having a typeset version readily available.

I suggest that we remove the PDF from the repository but instead I can
start including it in my nightly documentation builds. Any objections?

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170313/7895e946/attachment.sig>

From david at well-typed.com  Mon Mar 13 23:03:35 2017
From: david at well-typed.com (David Feuer)
Date: Mon, 13 Mar 2017 19:03:35 -0400
Subject: Removing core-spec.pdf from repository?
Message-ID: <4dkp8r5pbmj55dtk078hfkq9.1489446215751@email.android.com>

Kill it! That's terrible practice indeed. Speaking of generated files, it's time to check if our Unicode tables are up to date.


David FeuerWell-Typed, LLP
-------- Original message --------From: Ben Gamari <ben at well-typed.com> Date: 3/13/17  6:57 PM  (GMT-05:00) To: GHC developers <ghc-devs at haskell.org> Subject: Removing core-spec.pdf from repository? 
Hello everyone,

Currently there is a typeset copy of the Core specification in the GHC
repository. This means any time someone changes the specification the
repository grows by around 300kB. While this isn't the end of the
world, it's generally considered bad form to put generated files under
version control.

Of course, the tools required to typeset the specification (ott and
LaTeX) are non-trivial to install, so there is considerable convenience
that comes from having a typeset version readily available.

I suggest that we remove the PDF from the repository but instead I can
start including it in my nightly documentation builds. Any objections?

Cheers,

- Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170313/8d8a47f0/attachment-0001.html>

From ben at well-typed.com  Mon Mar 13 23:26:39 2017
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 13 Mar 2017 19:26:39 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <CAJumaK8q4yC0Dh3Hm8je6DieLLPGEuftyyzt6tUrYacORgiTng@mail.gmail.com>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <871su1m2xh.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK8q4yC0Dh3Hm8je6DieLLPGEuftyyzt6tUrYacORgiTng@mail.gmail.com>
Message-ID: <87lgs8lpw0.fsf@ben-laptop.smart-cactus.org>

Edward Kmett <ekmett at gmail.com> writes:

> That, rather tangentially, reminds me: If we do start to teach the code
> generator about how to produce these sorts of things from simpler parts,
> e.g. via enabling something like LLVM's vectorization pass, or some
> internal future ghc compiler pass that checks for, say, Superword-Level
> Parallelism
> <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.4663&rep=rep1&type=pdf>
> in the style of Jaewook Shin, then we need to differentiate between flags
> for what ghc/llvm is allowed to produce via optimization, etc. and what the
> end user is allowed to explicitly emit. e.g. in my own code I can safely
> call avx2 primitives after I set up guards to check that I'm on a CPU that
> supports them, but I can only currently emit that code after I tell GHC
> that I want it to allow the avx2 instructions. If I build a complicated
> dispatch mechanism in Haskell for picking the right ISA and emitting code
> for several of them, I'm going to need to tell ghc to let me build with all
> sorts of instruction sets that the machine the final executable runs on may
> not fully support. We should be careful not to conflate these two things.
>
Indeed this is tricky.

The obvious stop-gap solution is to simply move your various platform
dependent implementations into multiple modules. However, as you say
this quickly breaks down once GHC itself starts to learn vectorisation.
At that point you will need to draw the distinction you mention,
separating the ISA available to the user and that available to the
compiler.

Another related question is whether you eventually want a way to specify
an ISA per-function (via pragma, for instance). This would allow you to
set a conservative `-march` for the module on the whole, but allow use
of ISA extensions precisely when necessary. This is a bit tricky in the
face of inlining; perhaps you want to require only `NOINLINE` functions
can be decorated with such a thing.

I suspect in the case of LLVM this will require breaking modules up into
multiple compilation units and linking together the resulting objects.
This will certainly require a fair bit of engineering effort but nothing
terribly difficult.

Regarding dispatch, GCC has a function multi-versioning mechanism [1]
which is seems relevant to mention here. However, it's not entirely
clear to me whether the complexity here is worthwhile for GHC.

Anyways, there are plenty of possible options here; it would be helpful
to have a feature request ticket for the "user/compiler ISA" idea you
propose where we can collect ideas. Perhaps you could open one?

Cheers,

- Ben


[1] https://lwn.net/Articles/691666/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170313/33b230c8/attachment.sig>

From mail at joachim-breitner.de  Mon Mar 13 23:55:26 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 13 Mar 2017 19:55:26 -0400
Subject: Removing core-spec.pdf from repository?
In-Reply-To: <87o9x4lr8w.fsf@ben-laptop.smart-cactus.org>
References: <87o9x4lr8w.fsf@ben-laptop.smart-cactus.org>
Message-ID: <1489449326.8851.1.camel@joachim-breitner.de>

Hi,

Am Montag, den 13.03.2017, 18:57 -0400 schrieb Ben Gamari:
> I suggest that we remove the PDF from the repository but instead I can
> start including it in my nightly documentation builds. Any objections?

I also dislike generated files in repos, but would like to point out
that there are a few pages out there that reference the link
https://github.com/ghc/ghc/blob/master/docs/core-spec/core-spec.pdf
directly; these would brake. But there is probably nothing we can
easily do about that.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170313/99b2a7aa/attachment.sig>

From rf at rufflewind.com  Tue Mar 14 00:13:47 2017
From: rf at rufflewind.com (Phil Ruffwind)
Date: Mon, 13 Mar 2017 20:13:47 -0400
Subject: Removing core-spec.pdf from repository?
In-Reply-To: <1489449326.8851.1.camel@joachim-breitner.de>
References: <87o9x4lr8w.fsf@ben-laptop.smart-cactus.org>
 <1489449326.8851.1.camel@joachim-breitner.de>
Message-ID: <1489450427.1142024.910242968.27839224@webmail.messagingengine.com>

> I also dislike generated files in repos, but would like to point out
> that there are a few pages out there that reference the link
> https://github.com/ghc/ghc/blob/master/docs/core-spec/core-spec.pdf
> directly; these would brake. But there is probably nothing we can
> easily do about that.

Could replace it with a plain text file that says: "MOVED to
https://XXX"
The build system could then be tweaked to output the .pdf somewhere else
so it would not overwrite this dummy file.

From rae at cs.brynmawr.edu  Tue Mar 14 01:30:55 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Mon, 13 Mar 2017 21:30:55 -0400
Subject: Removing core-spec.pdf from repository?
In-Reply-To: <87o9x4lr8w.fsf@ben-laptop.smart-cactus.org>
References: <87o9x4lr8w.fsf@ben-laptop.smart-cactus.org>
Message-ID: <F277F540-A101-452A-8C90-367DE5F9C6F7@cs.brynmawr.edu>

Certainly no complaints from me. I knew I was doing a Bad Thing when I committed that file, but couldn't think of a good alternative, given the rarity of finding an ott installation.

Thanks, Ben.
Richard

> On Mar 13, 2017, at 6:57 PM, Ben Gamari <ben at well-typed.com> wrote:
> 
> Hello everyone,
> 
> Currently there is a typeset copy of the Core specification in the GHC
> repository. This means any time someone changes the specification the
> repository grows by around 300kB. While this isn't the end of the
> world, it's generally considered bad form to put generated files under
> version control.
> 
> Of course, the tools required to typeset the specification (ott and
> LaTeX) are non-trivial to install, so there is considerable convenience
> that comes from having a typeset version readily available.
> 
> I suggest that we remove the PDF from the repository but instead I can
> start including it in my nightly documentation builds. Any objections?
> 
> Cheers,
> 
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From matroxmike at icloud.com  Tue Mar 14 03:08:52 2017
From: matroxmike at icloud.com (Mike Hewitt)
Date: Tue, 14 Mar 2017 14:08:52 +1100
Subject: Removing core-spec.pdf from repository?
In-Reply-To: <1489450427.1142024.910242968.27839224@webmail.messagingengine.com>
References: <87o9x4lr8w.fsf@ben-laptop.smart-cactus.org>
 <1489449326.8851.1.camel@joachim-breitner.de>
 <1489450427.1142024.910242968.27839224@webmail.messagingengine.com>
Message-ID: <d3b38f5e-d781-a833-6d3b-39abaf21d4d4@icloud.com>

That would be a neat solution - I'd second that...


On 14/03/17 11:13, Phil Ruffwind wrote:
>> I also dislike generated files in repos, but would like to point out
>> that there are a few pages out there that reference the link
>> https://github.com/ghc/ghc/blob/master/docs/core-spec/core-spec.pdf
>> directly; these would brake. But there is probably nothing we can
>> easily do about that.
> Could replace it with a plain text file that says: "MOVED to
> https://XXX"
> The build system could then be tweaked to output the .pdf somewhere else
> so it would not overwrite this dummy file.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From takenobu.hs at gmail.com  Tue Mar 14 08:28:09 2017
From: takenobu.hs at gmail.com (Takenobu Tani)
Date: Tue, 14 Mar 2017 17:28:09 +0900
Subject: Removing core-spec.pdf from repository?
In-Reply-To: <87o9x4lr8w.fsf@ben-laptop.smart-cactus.org>
References: <87o9x4lr8w.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAPB_NvzQz3EPs42qRsw7jyd1TQYwySP+EaXJdv-YyooLH21tLQ@mail.gmail.com>

Hi devs,

How about putting it here every release? :
  https://downloads.haskell.org/~ghc/latest/docs/html/  or
  https://downloads.haskell.org/~ghc/latest/docs/

`core-spec.pdf` will be helpful.
But generating it in Windows is a bit complicated :)

Regards,
Takenobu


2017-03-14 7:57 GMT+09:00 Ben Gamari <ben at well-typed.com>:

> Hello everyone,
>
> Currently there is a typeset copy of the Core specification in the GHC
> repository. This means any time someone changes the specification the
> repository grows by around 300kB. While this isn't the end of the
> world, it's generally considered bad form to put generated files under
> version control.
>
> Of course, the tools required to typeset the specification (ott and
> LaTeX) are non-trivial to install, so there is considerable convenience
> that comes from having a typeset version readily available.
>
> I suggest that we remove the PDF from the repository but instead I can
> start including it in my nightly documentation builds. Any objections?
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170314/d2dbe83e/attachment.html>

From simonpj at microsoft.com  Tue Mar 14 08:38:16 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 14 Mar 2017 08:38:16 +0000
Subject: Removing core-spec.pdf from repository?
In-Reply-To: <1489450427.1142024.910242968.27839224@webmail.messagingengine.com>
References: <87o9x4lr8w.fsf@ben-laptop.smart-cactus.org>
 <1489449326.8851.1.camel@joachim-breitner.de>
 <1489450427.1142024.910242968.27839224@webmail.messagingengine.com>
Message-ID: <DM2PR21MB0028A5E2752CC067F3B1857AAD240@DM2PR21MB0028.namprd21.prod.outlook.com>

It's very helpful to have a live, up to date PDF.  Not everyone has OTT, which is required to make it.  And OTT isn't available on Windows at all :-(

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Phil
|  Ruffwind
|  Sent: 14 March 2017 00:14
|  To: ghc-devs at haskell.org
|  Subject: Re: Removing core-spec.pdf from repository?
|  
|  > I also dislike generated files in repos, but would like to point out
|  > that there are a few pages out there that reference the link
|  > https://github.com/ghc/ghc/blob/master/docs/core-spec/core-spec.pdf
|  > directly; these would brake. But there is probably nothing we can
|  > easily do about that.
|  
|  Could replace it with a plain text file that says: "MOVED to
|  https://XXX"
|  The build system could then be tweaked to output the .pdf somewhere
|  else so it would not overwrite this dummy file.
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From eacameron at gmail.com  Tue Mar 14 14:20:17 2017
From: eacameron at gmail.com (Elliot Cameron)
Date: Tue, 14 Mar 2017 10:20:17 -0400
Subject: Removing core-spec.pdf from repository?
In-Reply-To: <DM2PR21MB0028A5E2752CC067F3B1857AAD240@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <87o9x4lr8w.fsf@ben-laptop.smart-cactus.org>
 <1489449326.8851.1.camel@joachim-breitner.de>
 <1489450427.1142024.910242968.27839224@webmail.messagingengine.com>
 <DM2PR21MB0028A5E2752CC067F3B1857AAD240@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <CANPxu=xcENx-Tf_rWit54VfT7UiPu7xXwK+wwzjmAKx_nNTM7Q@mail.gmail.com>

The only loss is the ability to look at changes over time. If that's an
important feature, you could write the files with a commit hash in the
name. But that may not be worth it.

On Tue, Mar 14, 2017 at 4:38 AM, Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> It's very helpful to have a live, up to date PDF.  Not everyone has OTT,
> which is required to make it.  And OTT isn't available on Windows at all :-(
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Phil
> |  Ruffwind
> |  Sent: 14 March 2017 00:14
> |  To: ghc-devs at haskell.org
> |  Subject: Re: Removing core-spec.pdf from repository?
> |
> |  > I also dislike generated files in repos, but would like to point out
> |  > that there are a few pages out there that reference the link
> |  > https://github.com/ghc/ghc/blob/master/docs/core-spec/core-spec.pdf
> |  > directly; these would brake. But there is probably nothing we can
> |  > easily do about that.
> |
> |  Could replace it with a plain text file that says: "MOVED to
> |  https://XXX"
> |  The build system could then be tweaked to output the .pdf somewhere
> |  else so it would not overwrite this dummy file.
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170314/81b2478b/attachment.html>

From rf at rufflewind.com  Tue Mar 14 14:25:49 2017
From: rf at rufflewind.com (Phil Ruffwind)
Date: Tue, 14 Mar 2017 10:25:49 -0400
Subject: Removing core-spec.pdf from repository?
In-Reply-To: <CANPxu=xcENx-Tf_rWit54VfT7UiPu7xXwK+wwzjmAKx_nNTM7Q@mail.gmail.com>
References: <87o9x4lr8w.fsf@ben-laptop.smart-cactus.org>
 <1489449326.8851.1.camel@joachim-breitner.de>
 <1489450427.1142024.910242968.27839224@webmail.messagingengine.com>
 <DM2PR21MB0028A5E2752CC067F3B1857AAD240@DM2PR21MB0028.namprd21.prod.outlook.com>
 <CANPxu=xcENx-Tf_rWit54VfT7UiPu7xXwK+wwzjmAKx_nNTM7Q@mail.gmail.com>
Message-ID: <1489501549.3047951.910893904.110C9713@webmail.messagingengine.com>

On Tue, Mar 14, 2017, at 10:20, Elliot Cameron wrote:
> The only loss is the ability to look at changes over time.

GHC docs are archived for every version number:

https://downloads.haskell.org/~ghc/<version>/...

So it would remain possible to compare the changes between each release.
 The only problem is the discontinuity caused by this migration.

From ekmett at gmail.com  Tue Mar 14 18:29:56 2017
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 14 Mar 2017 14:29:56 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <87lgs8lpw0.fsf@ben-laptop.smart-cactus.org>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <871su1m2xh.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK8q4yC0Dh3Hm8je6DieLLPGEuftyyzt6tUrYacORgiTng@mail.gmail.com>
 <87lgs8lpw0.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAJumaK9vi0YRizhE==NQAH+cXFfEbbhHWZwf0_Wr7etZFJjZ-w@mail.gmail.com>

Hrmm. In C/C++ I can tell individual functions to turn on additional ISA
feature sets with compiler-specific __attribute__((target("avx2"))) tricks.
This avoids complains from the compiler when I call builtins that aren't
available at my current compilation feature level. Perhaps pragmas for the
codegen along those lines is what we'd ultimately need? Alternately, if we
simply distinguish between what the ghc codegen produces with one set of
options and what we're allowed to ask for explicitly with another then
user-land tricks like I employ would remain sound.

-Edward

On Mon, Mar 13, 2017 at 7:26 PM, Ben Gamari <ben at well-typed.com> wrote:

> Edward Kmett <ekmett at gmail.com> writes:
>
> > That, rather tangentially, reminds me: If we do start to teach the code
> > generator about how to produce these sorts of things from simpler parts,
> > e.g. via enabling something like LLVM's vectorization pass, or some
> > internal future ghc compiler pass that checks for, say, Superword-Level
> > Parallelism
> > <http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.
> 106.4663&rep=rep1&type=pdf>
> > in the style of Jaewook Shin, then we need to differentiate between flags
> > for what ghc/llvm is allowed to produce via optimization, etc. and what
> the
> > end user is allowed to explicitly emit. e.g. in my own code I can safely
> > call avx2 primitives after I set up guards to check that I'm on a CPU
> that
> > supports them, but I can only currently emit that code after I tell GHC
> > that I want it to allow the avx2 instructions. If I build a complicated
> > dispatch mechanism in Haskell for picking the right ISA and emitting code
> > for several of them, I'm going to need to tell ghc to let me build with
> all
> > sorts of instruction sets that the machine the final executable runs on
> may
> > not fully support. We should be careful not to conflate these two things.
> >
> Indeed this is tricky.
>
> The obvious stop-gap solution is to simply move your various platform
> dependent implementations into multiple modules. However, as you say
> this quickly breaks down once GHC itself starts to learn vectorisation.
> At that point you will need to draw the distinction you mention,
> separating the ISA available to the user and that available to the
> compiler.
>
> Another related question is whether you eventually want a way to specify
> an ISA per-function (via pragma, for instance). This would allow you to
> set a conservative `-march` for the module on the whole, but allow use
> of ISA extensions precisely when necessary. This is a bit tricky in the
> face of inlining; perhaps you want to require only `NOINLINE` functions
> can be decorated with such a thing.
>
> I suspect in the case of LLVM this will require breaking modules up into
> multiple compilation units and linking together the resulting objects.
> This will certainly require a fair bit of engineering effort but nothing
> terribly difficult.
>
> Regarding dispatch, GCC has a function multi-versioning mechanism [1]
> which is seems relevant to mention here. However, it's not entirely
> clear to me whether the complexity here is worthwhile for GHC.
>
> Anyways, there are plenty of possible options here; it would be helpful
> to have a feature request ticket for the "user/compiler ISA" idea you
> propose where we can collect ideas. Perhaps you could open one?
>
> Cheers,
>
> - Ben
>
>
> [1] https://lwn.net/Articles/691666/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170314/e00a3c94/attachment.html>

From michal.terepeta at gmail.com  Tue Mar 14 18:59:19 2017
From: michal.terepeta at gmail.com (Michal Terepeta)
Date: Tue, 14 Mar 2017 18:59:19 +0000
Subject: FYI: removing `fibon`
Message-ID: <CAEN7k7m7VCeyV9E5HOy-Vzzx0wzEPeAxrpvHiKu7TNowEFf9Yg@mail.gmail.com>

Hi all,

I wanted to remove `fibon` (from `nofib`) - it's broken, abandoned
upstream (no commits in 5 years) and I'm not aware of anyone using it
or working on it. At this point I don't think it makes sense to try to
revive it - I'd prefer putting the time/effort into getting a few new
benchmarks.

There were already discussions about removing it in
https://ghc.haskell.org/trac/ghc/ticket/11501

If someone is actually working on getting it to work again, please
shout!

Thanks,
Michal

PS. I've tried uploading the patch to Phab, but I think it's just too
large (arc is crashing). So I've uploaded it to github:
https://github.com/michalt/nofib/tree/fibon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170314/8c00f6ec/attachment.html>

From ben at well-typed.com  Tue Mar 14 20:02:26 2017
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 14 Mar 2017 16:02:26 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <CAJumaK9vi0YRizhE==NQAH+cXFfEbbhHWZwf0_Wr7etZFJjZ-w@mail.gmail.com>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <871su1m2xh.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK8q4yC0Dh3Hm8je6DieLLPGEuftyyzt6tUrYacORgiTng@mail.gmail.com>
 <87lgs8lpw0.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK9vi0YRizhE==NQAH+cXFfEbbhHWZwf0_Wr7etZFJjZ-w@mail.gmail.com>
Message-ID: <87efxzlj8t.fsf@ben-laptop.smart-cactus.org>

Edward Kmett <ekmett at gmail.com> writes:

> Hrmm. In C/C++ I can tell individual functions to turn on additional ISA
> feature sets with compiler-specific __attribute__((target("avx2"))) tricks.
> This avoids complains from the compiler when I call builtins that aren't
> available at my current compilation feature level. Perhaps pragmas for the
> codegen along those lines is what we'd ultimately need? Alternately, if we
> simply distinguish between what the ghc codegen produces with one set of
> options and what we're allowed to ask for explicitly with another then
> user-land tricks like I employ would remain sound.
>
I'm actually not sure that simply distinguishing between the user- and
codegen-allowed ISA extensions is quite sufficient. Afterall, AFAIK LLVM
doesn't make such a distinction itself: AFAIK if you write a vector
primitive and compile for a target that doesn't have an appropriate
instruction the code-generator will lower it with software emulation.

However, adding a pragma to allow per-function target annotations seems
quite reasonable and easily doable. Moreover, contrary to my previous
assertion, it shouldn't require any splitting of compilation units. I
ran a quick experiment, compiling this program,

    __attribute__((target("sse2"))) int hello() {
      return 1; 
    }

With clang. It produced something like,

    define i32 @hello() #0 {
      ret i32 1
    }

    attributes #0 = { "target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+sse,+sse2,+x87" ... }

So it seems LLVM is perfectly capable of expressing this; in hindsight
I'm not sure why I ever doubted this.

There are a number of details that would need to be worked out regarding
how such a pragma should behave. Does the general direction sound
reasonable? I've opened #13427 [1] to track this idea.

Cheers,

- Ben


[1] https://ghc.haskell.org/trac/ghc/ticket/13427
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170314/a4d3459e/attachment-0001.sig>

From gracjanpolak at gmail.com  Tue Mar 14 20:31:59 2017
From: gracjanpolak at gmail.com (Gracjan Polak)
Date: Tue, 14 Mar 2017 21:31:59 +0100
Subject: FYI: removing `fibon`
In-Reply-To: <CAEN7k7m7VCeyV9E5HOy-Vzzx0wzEPeAxrpvHiKu7TNowEFf9Yg@mail.gmail.com>
References: <CAEN7k7m7VCeyV9E5HOy-Vzzx0wzEPeAxrpvHiKu7TNowEFf9Yg@mail.gmail.com>
Message-ID: <CAChsM3T1TbWUtrCGuL6t72z+gbuTK71nJ9eqfZxweLk8nScaDg@mail.gmail.com>

I'm not working on it and do not plan to start again.

Looks like fibon never worked and wasn't used for anything, so it should be
removed. Still it would make sense to replace this code with something used
as part of normal nofib test cases.

2017-03-14 19:59 GMT+01:00 Michal Terepeta <michal.terepeta at gmail.com>:

> Hi all,
>
> I wanted to remove `fibon` (from `nofib`) - it's broken, abandoned
> upstream (no commits in 5 years) and I'm not aware of anyone using it
> or working on it. At this point I don't think it makes sense to try to
> revive it - I'd prefer putting the time/effort into getting a few new
> benchmarks.
>
> There were already discussions about removing it in
> https://ghc.haskell.org/trac/ghc/ticket/11501
>
> If someone is actually working on getting it to work again, please
> shout!
>
> Thanks,
> Michal
>
> PS. I've tried uploading the patch to Phab, but I think it's just too
> large (arc is crashing). So I've uploaded it to github:
> https://github.com/michalt/nofib/tree/fibon
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170314/b9ba9d76/attachment.html>

From mainland at apeiron.net  Tue Mar 14 20:32:36 2017
From: mainland at apeiron.net (Geoffrey Mainland)
Date: Tue, 14 Mar 2017 16:32:36 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <87efxzlj8t.fsf@ben-laptop.smart-cactus.org>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <871su1m2xh.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK8q4yC0Dh3Hm8je6DieLLPGEuftyyzt6tUrYacORgiTng@mail.gmail.com>
 <87lgs8lpw0.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK9vi0YRizhE==NQAH+cXFfEbbhHWZwf0_Wr7etZFJjZ-w@mail.gmail.com>
 <87efxzlj8t.fsf@ben-laptop.smart-cactus.org>
Message-ID: <4daf2ce2-3138-afda-ac2a-9bd36f07f50e@apeiron.net>

On 03/14/2017 04:02 PM, Ben Gamari wrote:
> Edward Kmett <ekmett at gmail.com> writes:
>
>> Hrmm. In C/C++ I can tell individual functions to turn on additional ISA
>> feature sets with compiler-specific __attribute__((target("avx2"))) tricks.
>> This avoids complains from the compiler when I call builtins that aren't
>> available at my current compilation feature level. Perhaps pragmas for the
>> codegen along those lines is what we'd ultimately need? Alternately, if we
>> simply distinguish between what the ghc codegen produces with one set of
>> options and what we're allowed to ask for explicitly with another then
>> user-land tricks like I employ would remain sound.
>>
> I'm actually not sure that simply distinguishing between the user- and
> codegen-allowed ISA extensions is quite sufficient. Afterall, AFAIK LLVM
> doesn't make such a distinction itself: AFAIK if you write a vector
> primitive and compile for a target that doesn't have an appropriate
> instruction the code-generator will lower it with software emulation.

This would mean that Haskell libraries compiled with different flags
would not be ABI compatible.

Our original paper exposed a Multi type class that was meant to be the
programmer interface to the primops. A Multi a would be the widest
vector type supported on the current architecture, so code that used a
Multi Double would always be guaranteed to work at the widest vector
type available for Double's.

The Multi approach explicitly eschewed lowering, but I would argue that
if performance is the goal, then automatic lowering is not what you
want. I would rather have the system pick the correct vector width for
me based on the current architecture.

This does nothing to solved the problem of ABI compatibility, which is
one reason I didn't push to get this upstreamed.

Is the Multi approach desirable? I think it would be nice to be able to
at least provide such a solution even if it isn't some sort of default.
Do we really want lowering of wider vector types?

Geoff

> However, adding a pragma to allow per-function target annotations seems
> quite reasonable and easily doable. Moreover, contrary to my previous
> assertion, it shouldn't require any splitting of compilation units. I
> ran a quick experiment, compiling this program,
>
>     __attribute__((target("sse2"))) int hello() {
>       return 1; 
>     }
>
> With clang. It produced something like,
>
>     define i32 @hello() #0 {
>       ret i32 1
>     }
>
>     attributes #0 = { "target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+sse,+sse2,+x87" ... }
>
> So it seems LLVM is perfectly capable of expressing this; in hindsight
> I'm not sure why I ever doubted this.
>
> There are a number of details that would need to be worked out regarding
> how such a pragma should behave. Does the general direction sound
> reasonable? I've opened #13427 [1] to track this idea.
>
> Cheers,
>
> - Ben
>
>
> [1] https://ghc.haskell.org/trac/ghc/ticket/13427




From carter.schonwald at gmail.com  Wed Mar 15 00:49:06 2017
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 15 Mar 2017 00:49:06 +0000
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <4daf2ce2-3138-afda-ac2a-9bd36f07f50e@apeiron.net>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <871su1m2xh.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK8q4yC0Dh3Hm8je6DieLLPGEuftyyzt6tUrYacORgiTng@mail.gmail.com>
 <87lgs8lpw0.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK9vi0YRizhE==NQAH+cXFfEbbhHWZwf0_Wr7etZFJjZ-w@mail.gmail.com>
 <87efxzlj8t.fsf@ben-laptop.smart-cactus.org>
 <4daf2ce2-3138-afda-ac2a-9bd36f07f50e@apeiron.net>
Message-ID: <CAHYVw0yig78gg3v-DfuAtFiemjnQZyD2e=XYqv_HpbO1RLOtjw@mail.gmail.com>

This thread is getting into a broader discussion about target specific
intrincsics as user prims vs compiler generated.

@ben - ed is talking about stuff like a function call that's using a
specific avx2 intrinsic, not the parameterized vector abstraction. LLvm
shouldn't be lowering those. ... or clang has issues :/

On Tue, Mar 14, 2017 at 4:33 PM Geoffrey Mainland <mainland at apeiron.net>
wrote:

> On 03/14/2017 04:02 PM, Ben Gamari wrote:
> > Edward Kmett <ekmett at gmail.com> writes:
> >
> >> Hrmm. In C/C++ I can tell individual functions to turn on additional ISA
> >> feature sets with compiler-specific __attribute__((target("avx2")))
> tricks.
> >> This avoids complains from the compiler when I call builtins that aren't
> >> available at my current compilation feature level. Perhaps pragmas for
> the
> >> codegen along those lines is what we'd ultimately need? Alternately, if
> we
> >> simply distinguish between what the ghc codegen produces with one set of
> >> options and what we're allowed to ask for explicitly with another then
> >> user-land tricks like I employ would remain sound.
> >>
> > I'm actually not sure that simply distinguishing between the user- and
> > codegen-allowed ISA extensions is quite sufficient. Afterall, AFAIK LLVM
> > doesn't make such a distinction itself: AFAIK if you write a vector
> > primitive and compile for a target that doesn't have an appropriate
> > instruction the code-generator will lower it with software emulation.
>
> This would mean that Haskell libraries compiled with different flags
> would not be ABI compatible.
>
> Our original paper exposed a Multi type class that was meant to be the
> programmer interface to the primops. A Multi a would be the widest
> vector type supported on the current architecture, so code that used a
> Multi Double would always be guaranteed to work at the widest vector
> type available for Double's.
>
> The Multi approach explicitly eschewed lowering, but I would argue that
> if performance is the goal, then automatic lowering is not what you
> want. I would rather have the system pick the correct vector width for
> me based on the current architecture.
>
> This does nothing to solved the problem of ABI compatibility, which is
> one reason I didn't push to get this upstreamed.
>
> Is the Multi approach desirable? I think it would be nice to be able to
> at least provide such a solution even if it isn't some sort of default.
> Do we really want lowering of wider vector types?
>
> Geoff
>
> > However, adding a pragma to allow per-function target annotations seems
> > quite reasonable and easily doable. Moreover, contrary to my previous
> > assertion, it shouldn't require any splitting of compilation units. I
> > ran a quick experiment, compiling this program,
> >
> >     __attribute__((target("sse2"))) int hello() {
> >       return 1;
> >     }
> >
> > With clang. It produced something like,
> >
> >     define i32 @hello() #0 {
> >       ret i32 1
> >     }
> >
> >     attributes #0 = { "target-cpu"="x86-64"
> "target-features"="+fxsr,+mmx,+sse,+sse2,+x87" ... }
> >
> > So it seems LLVM is perfectly capable of expressing this; in hindsight
> > I'm not sure why I ever doubted this.
> >
> > There are a number of details that would need to be worked out regarding
> > how such a pragma should behave. Does the general direction sound
> > reasonable? I've opened #13427 [1] to track this idea.
> >
> > Cheers,
> >
> > - Ben
> >
> >
> > [1] https://ghc.haskell.org/trac/ghc/ticket/13427
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170315/ea2e5d2a/attachment.html>

From siddhanathan+eml at gmail.com  Wed Mar 15 01:46:15 2017
From: siddhanathan+eml at gmail.com (Siddhanathan Shanmugam)
Date: Tue, 14 Mar 2017 18:46:15 -0700
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <CAHYVw0yig78gg3v-DfuAtFiemjnQZyD2e=XYqv_HpbO1RLOtjw@mail.gmail.com>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <871su1m2xh.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK8q4yC0Dh3Hm8je6DieLLPGEuftyyzt6tUrYacORgiTng@mail.gmail.com>
 <87lgs8lpw0.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK9vi0YRizhE==NQAH+cXFfEbbhHWZwf0_Wr7etZFJjZ-w@mail.gmail.com>
 <87efxzlj8t.fsf@ben-laptop.smart-cactus.org>
 <4daf2ce2-3138-afda-ac2a-9bd36f07f50e@apeiron.net>
 <CAHYVw0yig78gg3v-DfuAtFiemjnQZyD2e=XYqv_HpbO1RLOtjw@mail.gmail.com>
Message-ID: <CACxmOqkJ5yNc=iAe5Bff1KBMLJ+Gzrd__+MGBGY=3mz9KfCdqg@mail.gmail.com>

> I would be happy to advise if you would like to pick this up.

Thanks Ben!

> This would mean that Haskell libraries compiled with different flags
> would not be ABI compatible.

Wait, can we not maintain ABI compatibility if we limit the target
features using a compiler flag? Sometimes (for performance reasons)
it's reasonable to request the compiler to only generate SSE
instructions, even if AVX2 is available on the target. On GCC we can
use the flag -msse to do just that.

On Tue, Mar 14, 2017 at 5:49 PM, Carter Schonwald
<carter.schonwald at gmail.com> wrote:
> This thread is getting into a broader discussion about target specific
> intrincsics as user prims vs compiler generated.
>
> @ben - ed is talking about stuff like a function call that's using a
> specific avx2 intrinsic, not the parameterized vector abstraction. LLvm
> shouldn't be lowering those. ... or clang has issues :/
>
> On Tue, Mar 14, 2017 at 4:33 PM Geoffrey Mainland <mainland at apeiron.net>
> wrote:
>>
>> On 03/14/2017 04:02 PM, Ben Gamari wrote:
>> > Edward Kmett <ekmett at gmail.com> writes:
>> >
>> >> Hrmm. In C/C++ I can tell individual functions to turn on additional
>> >> ISA
>> >> feature sets with compiler-specific __attribute__((target("avx2")))
>> >> tricks.
>> >> This avoids complains from the compiler when I call builtins that
>> >> aren't
>> >> available at my current compilation feature level. Perhaps pragmas for
>> >> the
>> >> codegen along those lines is what we'd ultimately need? Alternately, if
>> >> we
>> >> simply distinguish between what the ghc codegen produces with one set
>> >> of
>> >> options and what we're allowed to ask for explicitly with another then
>> >> user-land tricks like I employ would remain sound.
>> >>
>> > I'm actually not sure that simply distinguishing between the user- and
>> > codegen-allowed ISA extensions is quite sufficient. Afterall, AFAIK LLVM
>> > doesn't make such a distinction itself: AFAIK if you write a vector
>> > primitive and compile for a target that doesn't have an appropriate
>> > instruction the code-generator will lower it with software emulation.
>>
>> This would mean that Haskell libraries compiled with different flags
>> would not be ABI compatible.
>>
>> Our original paper exposed a Multi type class that was meant to be the
>> programmer interface to the primops. A Multi a would be the widest
>> vector type supported on the current architecture, so code that used a
>> Multi Double would always be guaranteed to work at the widest vector
>> type available for Double's.
>>
>> The Multi approach explicitly eschewed lowering, but I would argue that
>> if performance is the goal, then automatic lowering is not what you
>> want. I would rather have the system pick the correct vector width for
>> me based on the current architecture.
>>
>> This does nothing to solved the problem of ABI compatibility, which is
>> one reason I didn't push to get this upstreamed.
>>
>> Is the Multi approach desirable? I think it would be nice to be able to
>> at least provide such a solution even if it isn't some sort of default.
>> Do we really want lowering of wider vector types?
>>
>> Geoff
>>
>> > However, adding a pragma to allow per-function target annotations seems
>> > quite reasonable and easily doable. Moreover, contrary to my previous
>> > assertion, it shouldn't require any splitting of compilation units. I
>> > ran a quick experiment, compiling this program,
>> >
>> >     __attribute__((target("sse2"))) int hello() {
>> >       return 1;
>> >     }
>> >
>> > With clang. It produced something like,
>> >
>> >     define i32 @hello() #0 {
>> >       ret i32 1
>> >     }
>> >
>> >     attributes #0 = { "target-cpu"="x86-64"
>> > "target-features"="+fxsr,+mmx,+sse,+sse2,+x87" ... }
>> >
>> > So it seems LLVM is perfectly capable of expressing this; in hindsight
>> > I'm not sure why I ever doubted this.
>> >
>> > There are a number of details that would need to be worked out regarding
>> > how such a pragma should behave. Does the general direction sound
>> > reasonable? I've opened #13427 [1] to track this idea.
>> >
>> > Cheers,
>> >
>> > - Ben
>> >
>> >
>> > [1] https://ghc.haskell.org/trac/ghc/ticket/13427
>>
>>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From simonpj at microsoft.com  Wed Mar 15 10:16:11 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 15 Mar 2017 10:16:11 +0000
Subject: [GHC] #13413: GHC HEAD panic: collectNBinders
In-Reply-To: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org>
References: <050.6d804c4277a4d5cd2b46bac7e943b7c6@haskell.org>
Message-ID: <DM2PR21MB00289DA760126291CFA8271BAD270@DM2PR21MB0028.namprd21.prod.outlook.com>

I know what is going on here.  I'm in a meeting all day, but I hope to fix tomorrow.

Simon

| -----Original Message-----
| From: ghc-tickets [mailto:ghc-tickets-bounces at haskell.org] On Behalf Of
| GHC
| Sent: 11 March 2017 20:12
| Cc: ghc-tickets at haskell.org
| Subject: [GHC] #13413: GHC HEAD panic: collectNBinders
| 
| #13413: GHC HEAD panic: collectNBinders
| -------------------------------------+----------------------------------
| -------------------------------------+---
|            Reporter:  RyanGlScott    |             Owner:  (none)
|                Type:  bug            |            Status:  new
|            Priority:  highest        |         Milestone:  8.2.1
|           Component:  Compiler       |           Version:  8.1
|            Keywords:  JoinPoints     |  Operating System:
| Unknown/Multiple
|        Architecture:                 |   Type of failure:  GHC rejects
|   Unknown/Multiple                   |  valid program
|           Test Case:                 |        Blocked By:
|            Blocking:                 |   Related Tickets:
| Differential Rev(s):                 |         Wiki Page:
| -------------------------------------+----------------------------------
| -------------------------------------+---
|  `repa-eval-4.2.3.1` currently fails to build on GHC HEAD because of this
| issue. Trying to build it leads to several `collectNBinders` panics is
| various modules. You can reproduce this by compiling this module:
| 
|  {{{#!hs
|  {-# LANGUAGE BangPatterns #-}
|  {-# LANGUAGE MagicHash #-}
|  module Data.Repa.Eval.Generic.Seq.Chunked where
| 
|  import GHC.Exts (Int#, (+#), (*#), (>=#))
| 
|  ------------------------------------------------------------------------
| -------
|  -- | Fill a block in a rank-2 array, sequentially.
|  --
|  --   * Blockwise filling can be more cache-efficient than linear filling
|  for
|  --     rank-2 arrays.
|  --
|  --   * The block is filled in row major order from top to bottom.
|  --
|  fillBlock2
|          :: (Int# -> a -> IO ()) -- ^ Update function to write into
| result  buffer.
|          -> (Int# -> Int# -> a)  -- ^ Function to get the value at an (x,
|  y) index.
|          -> Int#                 -- ^ Width of the whole array.
|          -> Int#                 -- ^ x0 lower left corner of block to
|  fill.
|          -> Int#                 -- ^ y0
|          -> Int#                 -- ^ w0 width of block to fill
|          -> Int#                 -- ^ h0 height of block to fill
|          -> IO ()
| 
|  fillBlock2
|          write getElem
|          !imageWidth !x0 !y0 !w0 h0
| 
|   = do   fillBlock y0 ix0
|   where  !x1     = x0 +# w0
|          !y1     = y0 +# h0
|          !ix0    = x0 +# (y0 *# imageWidth)
| 
|          {-# INLINE fillBlock #-}
|          fillBlock !y !ix
|           | 1# <- y >=# y1     = return ()
|           | otherwise
|           = do   fillLine1 x0 ix
|                  fillBlock (y +# 1#) (ix +# imageWidth)
| 
|           where  {-# INLINE fillLine1 #-}
|                  fillLine1 !x !ix'
|                   | 1# <- x >=# x1             = return ()
|                   | otherwise
|                   = do   write ix' (getElem x y)
|                          fillLine1 (x +# 1#) (ix' +# 1#)
| 
|  {-# INLINE [0] fillBlock2 #-}
|  }}}
| 
|  This compiles on GHC 8.0.2, but on GHC HEAD:
| 
|  {{{
|  $ ~/Software/ghc4/inplace/bin/ghc-stage2 -fforce-recomp Bug.hs
|  [1 of 1] Compiling Data.Repa.Eval.Generic.Seq.Chunked ( Bug.hs, Bug.o )
|  ghc-stage2: panic! (the 'impossible' happened)
|    (GHC version 8.1.20170201 for x86_64-unknown-linux):
|          collectNBinders
|    2
|    Call stack:
|        CallStack (from HasCallStack):
|          prettyCurrentCallStack, called at
|  compiler/utils/Outputable.hs:1179:58 in ghc:Outputable
|          callStackDoc, called at compiler/utils/Outputable.hs:1183:37 in
| ghc:Outputable
|          pprPanic, called at compiler/coreSyn/CoreSyn.hs:1970:25 in
| ghc:CoreSyn  }}}
| 
|  Interestingly, compiling this triggers the panic at any optimization
| level, but loading the module into GHCi does not cause it to panic.
| 
|  This regression was introduced in
| 8d5cf8bf584fd4849917c29d82dcf46ee75dd035
|  (Join points).
| 
| --
| Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13413>
| GHC <http://www.haskell.org/ghc/>
| The Glasgow Haskell Compiler

From david at well-typed.com  Wed Mar 15 10:38:00 2017
From: david at well-typed.com (David Feuer)
Date: Wed, 15 Mar 2017 06:38:00 -0400
Subject: Another strictness analysis wrinkle
Message-ID: <4vgp6hj74cikb06a4uy0fv6j.1489574280303@email.android.com>

I don't see how we can take advantage of this, but IO and ST seem quite different from a strictness analysis perspective. The whole I/O hack is completely unnecessary for ST. Ugh.

David FeuerWell-Typed, LLP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170315/6cc4bc9d/attachment.html>

From david at well-typed.com  Wed Mar 15 10:57:20 2017
From: david at well-typed.com (David Feuer)
Date: Wed, 15 Mar 2017 06:57:20 -0400
Subject: Another strictness analysis wrinkle
Message-ID: <4g761kp0gq1700nthi7sch9i.1489575440191@email.android.com>

Actually, I just had a thought. What if we ran ST computations with a different state token type? Say, State# FakeWorld? Would that let them escape the hack?


David FeuerWell-Typed, LLP
-------- Original message --------From: David Feuer <david at well-typed.com> Date: 3/15/17  6:38 AM  (GMT-05:00) To: GHC developers <ghc-devs at haskell.org> Subject: Another strictness analysis wrinkle 
I don't see how we can take advantage of this, but IO and ST seem quite different from a strictness analysis perspective. The whole I/O hack is completely unnecessary for ST. Ugh.

David FeuerWell-Typed, LLP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170315/c7b46275/attachment.html>

From ben at smart-cactus.org  Wed Mar 15 14:27:40 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 15 Mar 2017 10:27:40 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <CACxmOqkJ5yNc=iAe5Bff1KBMLJ+Gzrd__+MGBGY=3mz9KfCdqg@mail.gmail.com>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <871su1m2xh.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK8q4yC0Dh3Hm8je6DieLLPGEuftyyzt6tUrYacORgiTng@mail.gmail.com>
 <87lgs8lpw0.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK9vi0YRizhE==NQAH+cXFfEbbhHWZwf0_Wr7etZFJjZ-w@mail.gmail.com>
 <87efxzlj8t.fsf@ben-laptop.smart-cactus.org>
 <4daf2ce2-3138-afda-ac2a-9bd36f07f50e@apeiron.net>
 <CAHYVw0yig78gg3v-DfuAtFiemjnQZyD2e=XYqv_HpbO1RLOtjw@mail.gmail.com>
 <CACxmOqkJ5yNc=iAe5Bff1KBMLJ+Gzrd__+MGBGY=3mz9KfCdqg@mail.gmail.com>
Message-ID: <8737eelin7.fsf@ben-laptop.smart-cactus.org>

Siddhanathan Shanmugam <siddhanathan+eml at gmail.com> writes:

>> I would be happy to advise if you would like to pick this up.
>
> Thanks Ben!
>
>> This would mean that Haskell libraries compiled with different flags
>> would not be ABI compatible.
>
> Wait, can we not maintain ABI compatibility if we limit the target
> features using a compiler flag? Sometimes (for performance reasons)
> it's reasonable to request the compiler to only generate SSE
> instructions, even if AVX2 is available on the target. On GCC we can
> use the flag -msse to do just that.
>
I think the reasoning here is the following (please excuse the rather
contrived example): Consider a function f with two variants,

    module AvxImpl where
    {-# OPTIONS_GHC -mavx #-}
    f :: DoubleX4# -> DoubleX4# -> Double

    module SseImpl where
    {-# OPTIONS_GHC -msse #-}
    f :: DoubleX4# -> DoubleX4# -> Double

If we allow GHC to pass arguments with SIMD registers we now have a bit
of a conundrum: The calling convention for AvxImpl.f will require that
we pass the two arguments in YMM registers, whereas SseImpl.f will
be via passed some other means (perhaps two pairs of XMM registers).

In the C world this isn't a problem AFAIK since intrinsic types map
directly to register classes. Consequently, I can look at a C
declaration type,

    double f(__m256 x, __m256 y);

and tell you precisely the calling convention that would be used. In
GHC, however, we have an abstract vector model and therefore the calling
convention is determined by which ISA the compiler is targetting.

I really don't know how to fix this "correctly". Currently we assume
that there is a static mapping between STG registers and machine
registers. Giving this up sounds quite painful.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170315/7d776177/attachment.sig>

From carter.schonwald at gmail.com  Wed Mar 15 19:22:47 2017
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 15 Mar 2017 15:22:47 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <8737eelin7.fsf@ben-laptop.smart-cactus.org>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <871su1m2xh.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK8q4yC0Dh3Hm8je6DieLLPGEuftyyzt6tUrYacORgiTng@mail.gmail.com>
 <87lgs8lpw0.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK9vi0YRizhE==NQAH+cXFfEbbhHWZwf0_Wr7etZFJjZ-w@mail.gmail.com>
 <87efxzlj8t.fsf@ben-laptop.smart-cactus.org>
 <4daf2ce2-3138-afda-ac2a-9bd36f07f50e@apeiron.net>
 <CAHYVw0yig78gg3v-DfuAtFiemjnQZyD2e=XYqv_HpbO1RLOtjw@mail.gmail.com>
 <CACxmOqkJ5yNc=iAe5Bff1KBMLJ+Gzrd__+MGBGY=3mz9KfCdqg@mail.gmail.com>
 <8737eelin7.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAHYVw0xkQAZhFn+Obbe+zQwiU5fbxLbcFRnMv8kBfuLwp6Nkfg@mail.gmail.com>

solution: lets call these registers what they are, instead of pretending
they're portable. we are not going to find the right abstraction in the
first go. lets not do that. first get it working sanely, then figure out
proper abstractions

On Wed, Mar 15, 2017 at 10:27 AM, Ben Gamari <ben at smart-cactus.org> wrote:

> Siddhanathan Shanmugam <siddhanathan+eml at gmail.com> writes:
>
> >> I would be happy to advise if you would like to pick this up.
> >
> > Thanks Ben!
> >
> >> This would mean that Haskell libraries compiled with different flags
> >> would not be ABI compatible.
> >
> > Wait, can we not maintain ABI compatibility if we limit the target
> > features using a compiler flag? Sometimes (for performance reasons)
> > it's reasonable to request the compiler to only generate SSE
> > instructions, even if AVX2 is available on the target. On GCC we can
> > use the flag -msse to do just that.
> >
> I think the reasoning here is the following (please excuse the rather
> contrived example): Consider a function f with two variants,
>
>     module AvxImpl where
>     {-# OPTIONS_GHC -mavx #-}
>     f :: DoubleX4# -> DoubleX4# -> Double
>
>     module SseImpl where
>     {-# OPTIONS_GHC -msse #-}
>     f :: DoubleX4# -> DoubleX4# -> Double
>
> If we allow GHC to pass arguments with SIMD registers we now have a bit
> of a conundrum: The calling convention for AvxImpl.f will require that
> we pass the two arguments in YMM registers, whereas SseImpl.f will
> be via passed some other means (perhaps two pairs of XMM registers).
>
> In the C world this isn't a problem AFAIK since intrinsic types map
> directly to register classes. Consequently, I can look at a C
> declaration type,
>
>     double f(__m256 x, __m256 y);
>
> and tell you precisely the calling convention that would be used. In
> GHC, however, we have an abstract vector model and therefore the calling
> convention is determined by which ISA the compiler is targetting.
>
> I really don't know how to fix this "correctly". Currently we assume
> that there is a static mapping between STG registers and machine
> registers. Giving this up sounds quite painful.
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170315/19bbb713/attachment.html>

From carter.schonwald at gmail.com  Wed Mar 15 19:28:57 2017
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 15 Mar 2017 15:28:57 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
Message-ID: <CAHYVw0z5hg=yrw_8HYRhUgXagnpP-BFpqk1E=A85w95zuGfytQ@mail.gmail.com>

Ok so

1) xmm when not using fancy features

2) lets not have types that vary with the abi then!

i genuinely think that this is one of those domains where "no abstraction"
is a better starting point than "wrong abstraction"

I believe both edward kmett and I genuinely want to be users of simd on
ghc, and i think in both our cases, it would be markedly simpler to ground
the initial work in the ISA / CPU feature level operations/ register
flavors rather than trying to get ghc to do the "right abstraction" when we
have no experience even trying to bundle it up as a library. Lets get stuff
off the ground that doesn't mis-abstract, before we start hunting for the
right higher level tools on top.  No matter *how* ghc ultimately bundles
simd for high level programming, it *will* have to bottom out into these
target specific operations at code gen time, and LLVM is *not* an
abstraction for it.


On Fri, Mar 10, 2017 at 12:50 AM Siddhanathan Shanmugam <
siddhanathan+eml at gmail.com> wrote:

> > It would be even better if we could *also* teach the native back end about
> SSE instructions. Is there anyone who might be willing to work on that?
>
> Yes. Though, it would be better if someone with more experience than me
> decides to pick this up instead.
>
> On Thu, Mar 9, 2017 at 7:00 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
> If we only turn on ymm and zmm for passing explicit 256bit and 512bit
> vector types then changing the ABI would have basically zero effect on any
> code anybody is actually using today. Everything would remain abi
> compatible unless it involves the new types that nobody is using.
>
> This also has the benefit that turning on avx2 or avx512 wouldn't change
> the calling convention of any code, making it much safer to link code
> compiled with it on with code compiled with it off. That seems like a big
> deal.
>
> Moreover, if we start passing normal floats, etc. through them then our
> lack of shuffles and ways to get data in/out of them becomes quite a pain
> point.
>
> As for passing int/word data, passing the vectors of them through the ymm
> and zmm registers should be sufficient for the same reasons.
>
> -Edward
>
> On Thu, Mar 9, 2017 at 3:55 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
> zooming out:
>
> what *should* the new ABI be?
>
> Ed was suggesting we make all 16 xmm/ymm/ lower 16 zmm registers
> (depending on how they're being used) caller save,
>
> (what about all 32 zmm registers? would they be float only, or also for
> ints/words? simd has lots of nice int support!)
>
> a) if this doesn't cause any perf regressions i've no objections
>
> b) currently we only support passing floats/doubles and simd vectors of ,
> do we wanna support int/word data there too? (or are the GPR / general
> purpose registers enough for those? )
>
> c) other stuff i'm probably overlooking
>
> d) lets do this!
>
> On Thu, Mar 9, 2017 at 3:31 PM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
> the patch is still on TRAC,
>
> https://ghc.haskell.org/trac/ghc/ticket/8033
>
> we need to do changes to both the 32bit and 64bit ABIs, and I think thats
> where I got stalled from lack of feedback
>
> that aside:
>
> heres the original email thread on the llvm commits thread
> http://lists.llvm.org/pipermail/llvm-commits/Week-
> of-Mon-20130708/180264.html
>
> and theres links from there to the iterating on the test suite plus the
> original patch
>
> i'm more than happy to take a weekend to do the leg work, it was pretty
> fun last time.
>
> BUT, we need to agree on what ABI to do, and make sure that those ABI
> changes dont create a performance regression for some unexpected reason.
>
> On Thu, Mar 9, 2017 at 3:11 PM, Geoffrey Mainland <mainland at apeiron.net>
> wrote:
>
> We would need to get a patch to LLVM accepted to change the GHC calling
> convention.
>
> Now that we commit to a particular version of LLVM, this might be less
> of an issue than it once was since we wouldn't have to support versions
> of LLVM that didn't support the new calling convention.
>
> So...how do we get a patch into LLVM? I believe I once had such a patch
> ready to go...I will dig around for it, but the change is very small and
> easily recreated.
>
> It would be even better if we could *also* teach the native back end
> about SSE instructions. Is there anyone who might be willing to work on
> that?
>
> Geoff
>
> On 3/9/17 2:30 PM, Edward Kmett wrote:
> > Back around 2013, Geoff raised a discussion about fixing up the GHC
> > ABI so that the LLVM calling convention could pass 256 bit vector
> > types in YMM (and, i suppose now 512 bit vector types in ZMM).
> >
> > As I recall, this was blocked by some short term concerns about which
> > LLVM release was imminent or what have you. Four years on, the exact
> > same sort of arguments could be dredged up, but yet in the meantime
> > nobody is really using those types for anything.
> >
> > This still creates a pain point around trying to use these wide types
> > today. Spilling rather than passing them in registers adds a LOT of
> > overhead to any attempt to use them that virtually erases any benefit
> > to having them in the first place.
> >
> > I started experimenting with writing some custom primops directly in
> > llvm so I could do meaningful amounts of work with our SIMD vector
> > types by just banging out the code that we can't write in haskell
> > directly using llvm assembly, and hoping I could trick LLVM to do link
> > time optimization to perhaps inline it, but I'm basically dead in the
> > water over the overhead of our current calling convention, before I
> > even start, it seems, as if we're spilling them there is no way that
> > inlining / LTO could hope to figure out what we're doing out as part
> > of the spill to erase that call entirely.
> >
> > It is rather frustrating that I can't even cheat. =/
> >
> > What do we need to do to finally fix this?
> >
> > -Edward
>
>
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170315/f376c852/attachment-0001.html>

From ekmett at gmail.com  Wed Mar 15 19:29:29 2017
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 15 Mar 2017 15:29:29 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <8737eelin7.fsf@ben-laptop.smart-cactus.org>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <871su1m2xh.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK8q4yC0Dh3Hm8je6DieLLPGEuftyyzt6tUrYacORgiTng@mail.gmail.com>
 <87lgs8lpw0.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK9vi0YRizhE==NQAH+cXFfEbbhHWZwf0_Wr7etZFJjZ-w@mail.gmail.com>
 <87efxzlj8t.fsf@ben-laptop.smart-cactus.org>
 <4daf2ce2-3138-afda-ac2a-9bd36f07f50e@apeiron.net>
 <CAHYVw0yig78gg3v-DfuAtFiemjnQZyD2e=XYqv_HpbO1RLOtjw@mail.gmail.com>
 <CACxmOqkJ5yNc=iAe5Bff1KBMLJ+Gzrd__+MGBGY=3mz9KfCdqg@mail.gmail.com>
 <8737eelin7.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAJumaK-ib9vdO3sOh7E_FwLfGeuXncV_p8KcoTCuQYzfvAEfJA@mail.gmail.com>

Currently if you try to use a DoubleX4# and don't have AVX2 turned on, it
deliberately crashes out during code generation, no? So this is very
deliberately *not* a problem with the current setup as I understand it. It
only becomes one if we reverse the decision and decide to add terribly
inefficient shims for this functionality at the primop level rather than
have a higher level make the right call to just not use functionality that
isn't present on the target platform.

-Edward


On Wed, Mar 15, 2017 at 10:27 AM, Ben Gamari <ben at smart-cactus.org> wrote:

> Siddhanathan Shanmugam <siddhanathan+eml at gmail.com> writes:
>
> >> I would be happy to advise if you would like to pick this up.
> >
> > Thanks Ben!
> >
> >> This would mean that Haskell libraries compiled with different flags
> >> would not be ABI compatible.
> >
> > Wait, can we not maintain ABI compatibility if we limit the target
> > features using a compiler flag? Sometimes (for performance reasons)
> > it's reasonable to request the compiler to only generate SSE
> > instructions, even if AVX2 is available on the target. On GCC we can
> > use the flag -msse to do just that.
> >
> I think the reasoning here is the following (please excuse the rather
> contrived example): Consider a function f with two variants,
>
>     module AvxImpl where
>     {-# OPTIONS_GHC -mavx #-}
>     f :: DoubleX4# -> DoubleX4# -> Double
>
>     module SseImpl where
>     {-# OPTIONS_GHC -msse #-}
>     f :: DoubleX4# -> DoubleX4# -> Double
>
> If we allow GHC to pass arguments with SIMD registers we now have a bit
> of a conundrum: The calling convention for AvxImpl.f will require that
> we pass the two arguments in YMM registers, whereas SseImpl.f will
> be via passed some other means (perhaps two pairs of XMM registers).
>
> In the C world this isn't a problem AFAIK since intrinsic types map
> directly to register classes. Consequently, I can look at a C
> declaration type,
>
>     double f(__m256 x, __m256 y);
>
> and tell you precisely the calling convention that would be used. In
> GHC, however, we have an abstract vector model and therefore the calling
> convention is determined by which ISA the compiler is targetting.
>
> I really don't know how to fix this "correctly". Currently we assume
> that there is a static mapping between STG registers and machine
> registers. Giving this up sounds quite painful.
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170315/cef9e42f/attachment.html>

From carter.schonwald at gmail.com  Wed Mar 15 19:31:58 2017
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 15 Mar 2017 15:31:58 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <CAJumaK-ib9vdO3sOh7E_FwLfGeuXncV_p8KcoTCuQYzfvAEfJA@mail.gmail.com>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <871su1m2xh.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK8q4yC0Dh3Hm8je6DieLLPGEuftyyzt6tUrYacORgiTng@mail.gmail.com>
 <87lgs8lpw0.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK9vi0YRizhE==NQAH+cXFfEbbhHWZwf0_Wr7etZFJjZ-w@mail.gmail.com>
 <87efxzlj8t.fsf@ben-laptop.smart-cactus.org>
 <4daf2ce2-3138-afda-ac2a-9bd36f07f50e@apeiron.net>
 <CAHYVw0yig78gg3v-DfuAtFiemjnQZyD2e=XYqv_HpbO1RLOtjw@mail.gmail.com>
 <CACxmOqkJ5yNc=iAe5Bff1KBMLJ+Gzrd__+MGBGY=3mz9KfCdqg@mail.gmail.com>
 <8737eelin7.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK-ib9vdO3sOh7E_FwLfGeuXncV_p8KcoTCuQYzfvAEfJA@mail.gmail.com>
Message-ID: <CAHYVw0wv9wdowoUUdXVVobJGkHAbDC68v441BW4stJkKAO5mFA@mail.gmail.com>

agreed. and the generic vector size stuff in llvm is both pretty naive, AND
not the sane/tractable way to add SIMD support to the NCG,

i'm totally ok with my vector sizes that are available depending on the
target CPU or whatever. Operating systems have very sane errors for that
sort of mishap,

On Wed, Mar 15, 2017 at 3:29 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Currently if you try to use a DoubleX4# and don't have AVX2 turned on, it
> deliberately crashes out during code generation, no? So this is very
> deliberately *not* a problem with the current setup as I understand it.
> It only becomes one if we reverse the decision and decide to add terribly
> inefficient shims for this functionality at the primop level rather than
> have a higher level make the right call to just not use functionality that
> isn't present on the target platform.
>
> -Edward
>
>
> On Wed, Mar 15, 2017 at 10:27 AM, Ben Gamari <ben at smart-cactus.org> wrote:
>
>> Siddhanathan Shanmugam <siddhanathan+eml at gmail.com> writes:
>>
>> >> I would be happy to advise if you would like to pick this up.
>> >
>> > Thanks Ben!
>> >
>> >> This would mean that Haskell libraries compiled with different flags
>> >> would not be ABI compatible.
>> >
>> > Wait, can we not maintain ABI compatibility if we limit the target
>> > features using a compiler flag? Sometimes (for performance reasons)
>> > it's reasonable to request the compiler to only generate SSE
>> > instructions, even if AVX2 is available on the target. On GCC we can
>> > use the flag -msse to do just that.
>> >
>> I think the reasoning here is the following (please excuse the rather
>> contrived example): Consider a function f with two variants,
>>
>>     module AvxImpl where
>>     {-# OPTIONS_GHC -mavx #-}
>>     f :: DoubleX4# -> DoubleX4# -> Double
>>
>>     module SseImpl where
>>     {-# OPTIONS_GHC -msse #-}
>>     f :: DoubleX4# -> DoubleX4# -> Double
>>
>> If we allow GHC to pass arguments with SIMD registers we now have a bit
>> of a conundrum: The calling convention for AvxImpl.f will require that
>> we pass the two arguments in YMM registers, whereas SseImpl.f will
>> be via passed some other means (perhaps two pairs of XMM registers).
>>
>> In the C world this isn't a problem AFAIK since intrinsic types map
>> directly to register classes. Consequently, I can look at a C
>> declaration type,
>>
>>     double f(__m256 x, __m256 y);
>>
>> and tell you precisely the calling convention that would be used. In
>> GHC, however, we have an abstract vector model and therefore the calling
>> convention is determined by which ISA the compiler is targetting.
>>
>> I really don't know how to fix this "correctly". Currently we assume
>> that there is a static mapping between STG registers and machine
>> registers. Giving this up sounds quite painful.
>>
>> Cheers,
>>
>> - Ben
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170315/a39929fb/attachment.html>

From carter.schonwald at gmail.com  Wed Mar 15 19:37:20 2017
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Wed, 15 Mar 2017 15:37:20 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <CAHYVw0wv9wdowoUUdXVVobJGkHAbDC68v441BW4stJkKAO5mFA@mail.gmail.com>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <871su1m2xh.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK8q4yC0Dh3Hm8je6DieLLPGEuftyyzt6tUrYacORgiTng@mail.gmail.com>
 <87lgs8lpw0.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK9vi0YRizhE==NQAH+cXFfEbbhHWZwf0_Wr7etZFJjZ-w@mail.gmail.com>
 <87efxzlj8t.fsf@ben-laptop.smart-cactus.org>
 <4daf2ce2-3138-afda-ac2a-9bd36f07f50e@apeiron.net>
 <CAHYVw0yig78gg3v-DfuAtFiemjnQZyD2e=XYqv_HpbO1RLOtjw@mail.gmail.com>
 <CACxmOqkJ5yNc=iAe5Bff1KBMLJ+Gzrd__+MGBGY=3mz9KfCdqg@mail.gmail.com>
 <8737eelin7.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK-ib9vdO3sOh7E_FwLfGeuXncV_p8KcoTCuQYzfvAEfJA@mail.gmail.com>
 <CAHYVw0wv9wdowoUUdXVVobJGkHAbDC68v441BW4stJkKAO5mFA@mail.gmail.com>
Message-ID: <CAHYVw0wSFbR6AjHoBcaZ4Je1uGQ9k3fuErqwY7-uisc56-csZQ@mail.gmail.com>

to reiterate: any automated lowering / shimming scheme will hurt any
serious user of simd who isn't treating it as some black box abstraction.
And those are the very users who are equipped to write / design libraries /
ghc improvements that let still *other* users pretend to have a mostly
decent black box abstraction. Our compiler engineering bandwidth is not
enough to start with any automagic in this problem domain that isn't
validated with a model implementation in user space.

On Wed, Mar 15, 2017 at 3:31 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> agreed. and the generic vector size stuff in llvm is both pretty naive,
> AND not the sane/tractable way to add SIMD support to the NCG,
>
> i'm totally ok with my vector sizes that are available depending on the
> target CPU or whatever. Operating systems have very sane errors for that
> sort of mishap,
>
> On Wed, Mar 15, 2017 at 3:29 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> Currently if you try to use a DoubleX4# and don't have AVX2 turned on, it
>> deliberately crashes out during code generation, no? So this is very
>> deliberately *not* a problem with the current setup as I understand it.
>> It only becomes one if we reverse the decision and decide to add terribly
>> inefficient shims for this functionality at the primop level rather than
>> have a higher level make the right call to just not use functionality that
>> isn't present on the target platform.
>>
>> -Edward
>>
>>
>> On Wed, Mar 15, 2017 at 10:27 AM, Ben Gamari <ben at smart-cactus.org>
>> wrote:
>>
>>> Siddhanathan Shanmugam <siddhanathan+eml at gmail.com> writes:
>>>
>>> >> I would be happy to advise if you would like to pick this up.
>>> >
>>> > Thanks Ben!
>>> >
>>> >> This would mean that Haskell libraries compiled with different flags
>>> >> would not be ABI compatible.
>>> >
>>> > Wait, can we not maintain ABI compatibility if we limit the target
>>> > features using a compiler flag? Sometimes (for performance reasons)
>>> > it's reasonable to request the compiler to only generate SSE
>>> > instructions, even if AVX2 is available on the target. On GCC we can
>>> > use the flag -msse to do just that.
>>> >
>>> I think the reasoning here is the following (please excuse the rather
>>> contrived example): Consider a function f with two variants,
>>>
>>>     module AvxImpl where
>>>     {-# OPTIONS_GHC -mavx #-}
>>>     f :: DoubleX4# -> DoubleX4# -> Double
>>>
>>>     module SseImpl where
>>>     {-# OPTIONS_GHC -msse #-}
>>>     f :: DoubleX4# -> DoubleX4# -> Double
>>>
>>> If we allow GHC to pass arguments with SIMD registers we now have a bit
>>> of a conundrum: The calling convention for AvxImpl.f will require that
>>> we pass the two arguments in YMM registers, whereas SseImpl.f will
>>> be via passed some other means (perhaps two pairs of XMM registers).
>>>
>>> In the C world this isn't a problem AFAIK since intrinsic types map
>>> directly to register classes. Consequently, I can look at a C
>>> declaration type,
>>>
>>>     double f(__m256 x, __m256 y);
>>>
>>> and tell you precisely the calling convention that would be used. In
>>> GHC, however, we have an abstract vector model and therefore the calling
>>> convention is determined by which ISA the compiler is targetting.
>>>
>>> I really don't know how to fix this "correctly". Currently we assume
>>> that there is a static mapping between STG registers and machine
>>> registers. Giving this up sounds quite painful.
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170315/f4692e98/attachment-0001.html>

From mail at joachim-breitner.de  Wed Mar 15 20:12:42 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 15 Mar 2017 16:12:42 -0400
Subject: PSA: perf.haskell.org/ghc temporarily out of order
Message-ID: <1489608762.3047.8.camel@joachim-breitner.de>

Hi,

a recent change to nofib
(https://phabricator.haskell.org/rNOFIB313812d319e009d698bc1a4d2e8ac26d4dfe3c0a)
broke the perf.haskell.org builder, so we won’t be getting perf
warnings until that is fixed.

I hope that once its up we will not be faced with a large number of
performance changes that we will have to track down.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170315/1b04ce47/attachment.sig>

From ben at smart-cactus.org  Wed Mar 15 21:14:52 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 15 Mar 2017 17:14:52 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <CAJumaK-ib9vdO3sOh7E_FwLfGeuXncV_p8KcoTCuQYzfvAEfJA@mail.gmail.com>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <871su1m2xh.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK8q4yC0Dh3Hm8je6DieLLPGEuftyyzt6tUrYacORgiTng@mail.gmail.com>
 <87lgs8lpw0.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK9vi0YRizhE==NQAH+cXFfEbbhHWZwf0_Wr7etZFJjZ-w@mail.gmail.com>
 <87efxzlj8t.fsf@ben-laptop.smart-cactus.org>
 <4daf2ce2-3138-afda-ac2a-9bd36f07f50e@apeiron.net>
 <CAHYVw0yig78gg3v-DfuAtFiemjnQZyD2e=XYqv_HpbO1RLOtjw@mail.gmail.com>
 <CACxmOqkJ5yNc=iAe5Bff1KBMLJ+Gzrd__+MGBGY=3mz9KfCdqg@mail.gmail.com>
 <8737eelin7.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK-ib9vdO3sOh7E_FwLfGeuXncV_p8KcoTCuQYzfvAEfJA@mail.gmail.com>
Message-ID: <87wpbqjl83.fsf@ben-laptop.smart-cactus.org>

Edward Kmett <ekmett at gmail.com> writes:

> Currently if you try to use a DoubleX4# and don't have AVX2 turned on, it
> deliberately crashes out during code generation, no?

I very well be missing something, but I don't believe this is true. This
program compiles just fine with merely -fllvm -msse,

    {-# LANGUAGE MagicHash #-}
    {-# LANGUAGE UnboxedTuples #-}
    module Hi where
    import GHC.Prim
    import GHC.Float

    addIt :: DoubleX4# -> DoubleX4# -> DoubleX4#
    addIt x y = plusDoubleX4# x y
    {-# NOINLINE addIt #-}

It produces the following assembler,,

    movupd 0x10(%rbp),%xmm0
    movupd 0x0(%rbp),%xmm1
    movupd 0x30(%rbp),%xmm2
    movupd 0x20(%rbp),%xmm3
    addpd  %xmm1,%xmm3
    addpd  %xmm0,%xmm2
    movupd %xmm2,0x30(%rbp)
    movupd %xmm3,0x20(%rbp)
    mov    0x40(%rbp),%rax
    lea    0x20(%rbp),%rbp
    jmpq   *%rax

The reason for this is that the LLVM code generator just blindly
translates DoubleX4# to LLVM's <4 x double> type. The LLVM code
generator then does whatever it can to produce the code we ask of it,
even if the target doesn't have support for this vector variety.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170315/5d8eb6b2/attachment.sig>

From ben at smart-cactus.org  Wed Mar 15 21:21:03 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 15 Mar 2017 17:21:03 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <CAHYVw0xkQAZhFn+Obbe+zQwiU5fbxLbcFRnMv8kBfuLwp6Nkfg@mail.gmail.com>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <871su1m2xh.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK8q4yC0Dh3Hm8je6DieLLPGEuftyyzt6tUrYacORgiTng@mail.gmail.com>
 <87lgs8lpw0.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK9vi0YRizhE==NQAH+cXFfEbbhHWZwf0_Wr7etZFJjZ-w@mail.gmail.com>
 <87efxzlj8t.fsf@ben-laptop.smart-cactus.org>
 <4daf2ce2-3138-afda-ac2a-9bd36f07f50e@apeiron.net>
 <CAHYVw0yig78gg3v-DfuAtFiemjnQZyD2e=XYqv_HpbO1RLOtjw@mail.gmail.com>
 <CACxmOqkJ5yNc=iAe5Bff1KBMLJ+Gzrd__+MGBGY=3mz9KfCdqg@mail.gmail.com>
 <8737eelin7.fsf@ben-laptop.smart-cactus.org>
 <CAHYVw0xkQAZhFn+Obbe+zQwiU5fbxLbcFRnMv8kBfuLwp6Nkfg@mail.gmail.com>
Message-ID: <87tw6ujkxs.fsf@ben-laptop.smart-cactus.org>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> solution: lets call these registers what they are, instead of pretending
> they're portable. we are not going to find the right abstraction in the
> first go. lets not do that. first get it working sanely, then figure out
> proper abstractions
>
I'm not sure I understand what you are suggesting here. Are you
suggesting we rename the types and primops in the Haskell interface?
Some deeper change in semantics? Their treatment in the compiler
backend? Something else entirely?

I'm lost.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170315/ccce8451/attachment.sig>

From ben at smart-cactus.org  Wed Mar 15 21:38:51 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 15 Mar 2017 17:38:51 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <CAHYVw0wv9wdowoUUdXVVobJGkHAbDC68v441BW4stJkKAO5mFA@mail.gmail.com>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <871su1m2xh.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK8q4yC0Dh3Hm8je6DieLLPGEuftyyzt6tUrYacORgiTng@mail.gmail.com>
 <87lgs8lpw0.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK9vi0YRizhE==NQAH+cXFfEbbhHWZwf0_Wr7etZFJjZ-w@mail.gmail.com>
 <87efxzlj8t.fsf@ben-laptop.smart-cactus.org>
 <4daf2ce2-3138-afda-ac2a-9bd36f07f50e@apeiron.net>
 <CAHYVw0yig78gg3v-DfuAtFiemjnQZyD2e=XYqv_HpbO1RLOtjw@mail.gmail.com>
 <CACxmOqkJ5yNc=iAe5Bff1KBMLJ+Gzrd__+MGBGY=3mz9KfCdqg@mail.gmail.com>
 <8737eelin7.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK-ib9vdO3sOh7E_FwLfGeuXncV_p8KcoTCuQYzfvAEfJA@mail.gmail.com>
 <CAHYVw0wv9wdo
 woUUdXVVobJGkHAbDC68v441BW4stJkKAO5mFA@mail.gmail.com>
Message-ID: <87r31yjk44.fsf@ben-laptop.smart-cactus.org>

It's a bit unclear from this comment whether this statement is a
critique of a particular implementation strategy for adding SIMD support
to the NCG or a more general reflection on SIMD interfaces. From your
later messages I infer the latter in my response; feel free to disregard
if I misinterpreted.

Carter Schonwald <carter.schonwald at gmail.com> writes:

> agreed. and the generic vector size stuff in llvm is both pretty
> naive, AND not the sane/tractable way to add SIMD support to the NCG,
>
I don't see why this is true. I think it's fair to say that the LLVM
folks have put a lot more thought into SIMD support than any of us here;
consequently I tend to put a fair amount of trust in what they have to
say about the matter. Moreover, it seems to me like they came up with a
pretty sensible abstraction from which they can produce very good code.

Is the abstraction perfect? Of course not; they poke holes where
necessary to expose truly platform specific functionality. However, it
seems they rarely find it necessary to use these holes: In playing
around with Clang I found that almost all of the standard vector
operations lowered to the "naive" abstract operations.

I don't see why we can't provide a similar approach: provide abstract
types and some basic operations (as we already do), supplemented with
tailored primops far target-specific functionality.

My generally, I think we should have a very good reason before we go off
and chart our own course here.

> i'm totally ok with my vector sizes that are available depending on the
> target CPU or whatever. Operating systems have very sane errors for that
> sort of mishap,
>
If the user wants to be more careful about using precisely the vector
support that their target offers then that is their perogative. Unless
I'm missing something there is nothing stopping them under the current
scheme.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170315/dfe1934d/attachment.sig>

From ben at smart-cactus.org  Wed Mar 15 21:44:24 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 15 Mar 2017 17:44:24 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <CAHYVw0z5hg=yrw_8HYRhUgXagnpP-BFpqk1E=A85w95zuGfytQ@mail.gmail.com>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <CAHYVw0z5hg=yrw_8HYRhUgXagnpP-BFpqk1E=A85w95zuGfytQ@mail.gmail.com>
Message-ID: <87o9x2jjuv.fsf@ben-laptop.smart-cactus.org>

Carter Schonwald <carter.schonwald at gmail.com> writes:

> No matter *how* ghc ultimately bundles simd for high level
> programming, it *will* have to bottom out into these target specific
> operations at code gen time, and LLVM is *not* an abstraction for it.
>
I am very interested to hear what you mean by this; please do elaborate.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170315/bebc4447/attachment.sig>

From ekmett at gmail.com  Wed Mar 15 21:46:43 2017
From: ekmett at gmail.com (Edward Kmett)
Date: Wed, 15 Mar 2017 17:46:43 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <87wpbqjl83.fsf@ben-laptop.smart-cactus.org>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <871su1m2xh.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK8q4yC0Dh3Hm8je6DieLLPGEuftyyzt6tUrYacORgiTng@mail.gmail.com>
 <87lgs8lpw0.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK9vi0YRizhE==NQAH+cXFfEbbhHWZwf0_Wr7etZFJjZ-w@mail.gmail.com>
 <87efxzlj8t.fsf@ben-laptop.smart-cactus.org>
 <4daf2ce2-3138-afda-ac2a-9bd36f07f50e@apeiron.net>
 <CAHYVw0yig78gg3v-DfuAtFiemjnQZyD2e=XYqv_HpbO1RLOtjw@mail.gmail.com>
 <CACxmOqkJ5yNc=iAe5Bff1KBMLJ+Gzrd__+MGBGY=3mz9KfCdqg@mail.gmail.com>
 <8737eelin7.fsf@ben-laptop.smart-cactus.org>
 <CAJumaK-ib9vdO3sOh7E_FwLfGeuXncV_p8KcoTCuQYzfvAEfJA@mail.gmail.com>
 <87wpbqjl83.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAJumaK_acYMFU9++dcvZ9A8S0x7SKiesd+5QuPY_P6r73ChcAA@mail.gmail.com>

Ugh. I apparently had a misunderstanding about how that was compiled.

-Edward

On Wed, Mar 15, 2017 at 5:14 PM, Ben Gamari <ben at smart-cactus.org> wrote:

> Edward Kmett <ekmett at gmail.com> writes:
>
> > Currently if you try to use a DoubleX4# and don't have AVX2 turned on, it
> > deliberately crashes out during code generation, no?
>
> I very well be missing something, but I don't believe this is true. This
> program compiles just fine with merely -fllvm -msse,
>
>     {-# LANGUAGE MagicHash #-}
>     {-# LANGUAGE UnboxedTuples #-}
>     module Hi where
>     import GHC.Prim
>     import GHC.Float
>
>     addIt :: DoubleX4# -> DoubleX4# -> DoubleX4#
>     addIt x y = plusDoubleX4# x y
>     {-# NOINLINE addIt #-}
>
> It produces the following assembler,,
>
>     movupd 0x10(%rbp),%xmm0
>     movupd 0x0(%rbp),%xmm1
>     movupd 0x30(%rbp),%xmm2
>     movupd 0x20(%rbp),%xmm3
>     addpd  %xmm1,%xmm3
>     addpd  %xmm0,%xmm2
>     movupd %xmm2,0x30(%rbp)
>     movupd %xmm3,0x20(%rbp)
>     mov    0x40(%rbp),%rax
>     lea    0x20(%rbp),%rbp
>     jmpq   *%rax
>
> The reason for this is that the LLVM code generator just blindly
> translates DoubleX4# to LLVM's <4 x double> type. The LLVM code
> generator then does whatever it can to produce the code we ask of it,
> even if the target doesn't have support for this vector variety.
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170315/d8418874/attachment.html>

From allbery.b at gmail.com  Wed Mar 15 21:47:00 2017
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 15 Mar 2017 17:47:00 -0400
Subject: LLVM calling convention for AVX2 and AVX512 registers
In-Reply-To: <87o9x2jjuv.fsf@ben-laptop.smart-cactus.org>
References: <CAJumaK-pPhj2oh_D2m+LM7j0UTUGbTz3XKiGikKPsC9JyBaXSQ@mail.gmail.com>
 <42a9df15-05db-d9ce-eda7-4c8f9f12dd96@apeiron.net>
 <CAHYVw0ydP4FBOkSzp+8-nxYpN_Pvf+b_hZfFwF4oQUpmno+PrQ@mail.gmail.com>
 <CAHYVw0zr1atpQZp3BRrzxemmAnW=0r6UaEV_B0JgPW113SzCMA@mail.gmail.com>
 <CAJumaK-yqVVKgS=EcxYnuToKs8OmLMh7bfpRfJJXwQ2uT6S0jg@mail.gmail.com>
 <CACxmOqmG6iPLR4Sp3UHBEQa9u5rgsXmxEfynACbiqMS=BKBwng@mail.gmail.com>
 <CAHYVw0z5hg=yrw_8HYRhUgXagnpP-BFpqk1E=A85w95zuGfytQ@mail.gmail.com>
 <87o9x2jjuv.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAKFCL4U3w2DXfjcHiLNhFgbDXKv4timYh3gsymcEfQ6F_m_e7Q@mail.gmail.com>

On Wed, Mar 15, 2017 at 5:44 PM, Ben Gamari <ben at smart-cactus.org> wrote:

> Carter Schonwald <carter.schonwald at gmail.com> writes:
>
> > No matter *how* ghc ultimately bundles simd for high level
> > programming, it *will* have to bottom out into these target specific
> > operations at code gen time, and LLVM is *not* an abstraction for it.
> >
> I am very interested to hear what you mean by this; please do elaborate.
>

I'm a bit puzzled by this, as this is pretty much the exact kind of
abstraction LLVM is intended for as I understand it.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170315/6a72e1c7/attachment-0001.html>

From ben at smart-cactus.org  Wed Mar 15 21:49:51 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 15 Mar 2017 17:49:51 -0400
Subject: PSA: perf.haskell.org/ghc temporarily out of order
In-Reply-To: <1489608762.3047.8.camel@joachim-breitner.de>
References: <1489608762.3047.8.camel@joachim-breitner.de>
Message-ID: <87lgs6jjls.fsf@ben-laptop.smart-cactus.org>

Joachim Breitner <mail at joachim-breitner.de> writes:

> Hi,
>
> a recent change to nofib
> (https://phabricator.haskell.org/rNOFIB313812d319e009d698bc1a4d2e8ac26d4dfe3c0a)
> broke the perf.haskell.org builder, so we won’t be getting perf
> warnings until that is fixed.
>
I've pushed the michalt's fix. Thanks for the quick turnaround, michalt!

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170315/46c51af2/attachment.sig>

From david at well-typed.com  Thu Mar 16 08:19:45 2017
From: david at well-typed.com (David Feuer)
Date: Thu, 16 Mar 2017 04:19:45 -0400
Subject: Bounding I/O imprecision
Message-ID: <otdog8wir652owf3joyagqef.1489650913363@email.android.com>

Thinking more about this I/O demand analysis thing. I don't think it's possible for the compiler to decide for itself what to fuzz, but a user might know very well. Given
m >>= f
there are really two sensible approaches:
1. Want to ensure m is executed even if the action produced by f will diverge.
2. Not care whether m is executed if the compound action will ultimately diverge.
Our current I/O hack mixes these two in an unprincipled way.
The second approach, not caring, is certainly the most natural for GHC's implementation of I/O: we're defining a function from the real world to a new real world and a value; the function is partial and we don't care about the details. This is fairly clearly the right way to handle strict ST: if we don't get a result at the end, we don't get anything useful and don't care what actions get dropped.
The first approach seems to offer a better way to explain I/O and evaluation to users, ensuring that evaluation is only performed to the extent necessary for execution. This is partially supported by the I/O hack when it triggers. But it doesn't always, and it's not entirely clear if we can make do so.
Still no real conclusions here; just exploring the problem more.
David FeuerWell-Typed, LLP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170316/f4d42a3e/attachment.html>

From simonpj at microsoft.com  Thu Mar 16 17:49:43 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 16 Mar 2017 17:49:43 +0000
Subject: Adding a module
Message-ID: <DM2PR21MB00289EAD707799C988AF4673AD260@DM2PR21MB0028.namprd21.prod.outlook.com>

If you add a module to GHC, I know you need to extend ghc.cabal.in.   But also ghc.mk? Otherwise I get hits


If you add a module to GHC, I know you need to extend ghc.cabal.in.   But also ghc.mk? Otherwise I get hits
/usr/bin/ar: creating rts/dist/build/libHSrts_debug.a

Reachable modules from DynFlags out of date

Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780)

Extra modules: CoreOpt

make[1]: *** [compiler/stage2/dll-split.stamp] Error 1

make[1]: *** Waiting for unfinished jobs....

make: *** [all] Error 2


Is it necessary to have two places to extend?

Simon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170316/5ea272c3/attachment.html>

From ezyang at mit.edu  Thu Mar 16 18:02:54 2017
From: ezyang at mit.edu (Edward Z. Yang)
Date: Thu, 16 Mar 2017 11:02:54 -0700
Subject: Adding a module
In-Reply-To: <DM2PR21MB00289EAD707799C988AF4673AD260@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <DM2PR21MB00289EAD707799C988AF4673AD260@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <1489687324-sup-7722@sabre>

That's correct: if you add a module which is (indirectly) imported
by DynFlags, you have to tell ghc.mk about it so that the Windows
DLL splitting hack continues to work.

Edward

Excerpts from Simon Peyton Jones via ghc-devs's message of 2017-03-16 17:49:43 +0000:
> If you add a module to GHC, I know you need to extend ghc.cabal.in.   But also ghc.mk? Otherwise I get hits
> 
> 
> If you add a module to GHC, I know you need to extend ghc.cabal.in.   But also ghc.mk? Otherwise I get hits
> /usr/bin/ar: creating rts/dist/build/libHSrts_debug.a
> 
> Reachable modules from DynFlags out of date
> 
> Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780)
> 
> Extra modules: CoreOpt
> 
> make[1]: *** [compiler/stage2/dll-split.stamp] Error 1
> 
> make[1]: *** Waiting for unfinished jobs....
> 
> make: *** [all] Error 2
> 
> 
> Is it necessary to have two places to extend?
> 
> Simon

From ben at smart-cactus.org  Thu Mar 16 18:13:22 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 16 Mar 2017 14:13:22 -0400
Subject: Adding a module
In-Reply-To: <DM2PR21MB00289EAD707799C988AF4673AD260@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <DM2PR21MB00289EAD707799C988AF4673AD260@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <87a88ljdj1.fsf@ben-laptop.smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> If you add a module to GHC, I know you need to extend ghc.cabal.in.   But also ghc.mk? Otherwise I get hits
>
>
> If you add a module to GHC, I know you need to extend ghc.cabal.in.   But also ghc.mk? Otherwise I get hits
> /usr/bin/ar: creating rts/dist/build/libHSrts_debug.a
>
> Reachable modules from DynFlags out of date
>
> Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780)
>
> Extra modules: CoreOpt
>
> make[1]: *** [compiler/stage2/dll-split.stamp] Error 1
>
> make[1]: *** Waiting for unfinished jobs....
>
> make: *** [all] Error 2
>
>
> Is it necessary to have two places to extend?
>
Well, I suppose we might be able to compute the list of accessible
modules instead of listing them by hand. However, I'm not sure that this
would be worth the complexity it would introduce.

Moreover, I believe that Tamar is working towards being able to entirely
lift the need for this list (please correct me if I'm wrong, Tamar). If
things go well his work should be in 8.4.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170316/2b72902a/attachment.sig>

From lonetiger at gmail.com  Thu Mar 16 18:18:17 2017
From: lonetiger at gmail.com (Phyx)
Date: Thu, 16 Mar 2017 18:18:17 +0000
Subject: Adding a module
In-Reply-To: <1489687324-sup-7722@sabre>
References: <DM2PR21MB00289EAD707799C988AF4673AD260@DM2PR21MB0028.namprd21.prod.outlook.com>
 <1489687324-sup-7722@sabre>
Message-ID: <CABHktDUHxXhD7V-F1Z0W9x3wekmci54LaEG8oLn23tUgDvrzjw@mail.gmail.com>

My current patch on phabricator.haskell.org does do away with this and
instead implements an automatic partitioning scheme which also scales.

I have just not resolved all the issues yet to be able to push it with
dynamic linking on. Although it might be worth for me to disable dynamic
linking and push the current one as to get dll-split gone and to make the
required build system changes.

On Thu, 16 Mar 2017, 18:03 Edward Z. Yang, <ezyang at mit.edu> wrote:

That's correct: if you add a module which is (indirectly) imported
by DynFlags, you have to tell ghc.mk about it so that the Windows
DLL splitting hack continues to work.

Edward

Excerpts from Simon Peyton Jones via ghc-devs's message of 2017-03-16
17:49:43 +0000:
> If you add a module to GHC, I know you need to extend ghc.cabal.in.   But
also ghc.mk? Otherwise I get hits
>
>
> If you add a module to GHC, I know you need to extend ghc.cabal.in.   But
also ghc.mk? Otherwise I get hits
> /usr/bin/ar: creating rts/dist/build/libHSrts_debug.a
>
> Reachable modules from DynFlags out of date
>
> Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780)
>
> Extra modules: CoreOpt
>
> make[1]: *** [compiler/stage2/dll-split.stamp] Error 1
>
> make[1]: *** Waiting for unfinished jobs....
>
> make: *** [all] Error 2
>
>
> Is it necessary to have two places to extend?
>
> Simon
_______________________________________________
ghc-devs mailing list
ghc-devs at haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170316/a263cba7/attachment.html>

From simonpj at microsoft.com  Fri Mar 17 17:48:39 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 17 Mar 2017 17:48:39 +0000
Subject: Stat too good
Message-ID: <DM2PR21MB00287BC411A0F38B802280B1AD390@DM2PR21MB0028.namprd21.prod.outlook.com>

Ben,
I still get these four stat-too-good "failures" on 64-bit Linux.

Unexpected stat failures:

   /tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T13035.run  T13035 [stat too good] (normal)

   /tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T12425.run  T12425 [stat too good] (optasm)

   /tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T1969.run   T1969 [stat too good] (normal)

   /tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T9233.run   T9233 [stat too good] (normal)
Don't you?
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170317/747e617f/attachment.html>

From rwbarton at gmail.com  Sat Mar 18 05:56:42 2017
From: rwbarton at gmail.com (Reid Barton)
Date: Sat, 18 Mar 2017 01:56:42 -0400
Subject: PSA: perf.haskell.org/ghc temporarily out of order
In-Reply-To: <87lgs6jjls.fsf@ben-laptop.smart-cactus.org>
References: <1489608762.3047.8.camel@joachim-breitner.de>
 <87lgs6jjls.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CADmwj46xvrEy4cX1M4bFi7oGD-Qw6x4NbyyVUDzLm0Uqr3s-gw@mail.gmail.com>

Don't know whether it is the same issue, but perf.haskell.org seems to
still have not built anything for the past 3 days, according to
https://github.com/nomeata/ghc-speed-logs/commits/master.

Regards,
Reid Barton

On Wed, Mar 15, 2017 at 5:49 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> Joachim Breitner <mail at joachim-breitner.de> writes:
>
>> Hi,
>>
>> a recent change to nofib
>> (https://phabricator.haskell.org/rNOFIB313812d319e009d698bc1a4d2e8ac26d4dfe3c0a)
>> broke the perf.haskell.org builder, so we won’t be getting perf
>> warnings until that is fixed.
>>
> I've pushed the michalt's fix. Thanks for the quick turnaround, michalt!
>
> Cheers,
>
> - Ben
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From alan.zimm at gmail.com  Sat Mar 18 12:36:56 2017
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Sat, 18 Mar 2017 14:36:56 +0200
Subject: Travis again over time
In-Reply-To: <1489079840.12255.1.camel@joachim-breitner.de>
References: <1488657386.11972.3.camel@joachim-breitner.de>
 <1488728220.8321.0.camel@joachim-breitner.de>
 <1488893957.3556.4.camel@joachim-breitner.de>
 <1489079840.12255.1.camel@joachim-breitner.de>
Message-ID: <CANma=H8e5738rJ+PGN9QM2FSKKjNx6EAmBYK7GHbJWsMSKaYzw@mail.gmail.com>

FYI, liquidhaskell switched from travis to circleci.com because of timeout
problems.

It seems the time available is larger there.

And you get access to the build artifacts afterward, as per your
configuration.

Alan

On 9 March 2017 at 19:17, Joachim Breitner <mail at joachim-breitner.de> wrote:

> Hi,
>
> Am Dienstag, den 07.03.2017, 14:39 +0100 schrieb Joachim Breitner:
> > The build would be marked as passing if it were not for
> > integerConstantFolding which is marked as …
>
> fixed this issue. Travis should pass now again. Let’s keep it this way!
>
> Greetings,
> Joachim
>
> --
> Joachim “nomeata” Breitner
>   mail at joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170318/e7d4b210/attachment.html>

From syd.kerckhove at gmail.com  Sat Mar 18 13:03:48 2017
From: syd.kerckhove at gmail.com (Tom Sydney Kerckhove)
Date: Sat, 18 Mar 2017 14:03:48 +0100
Subject: Why are there no Show instances for internal types
Message-ID: <20170318130348.GC25078@quintus.localdomain>

Dear GHC Devs,

I am trying to use GHC as a library but I'm having a lot of trouble with
understanding what everything means.
Up to now, I have been able to figure out what to do by reading the
sources, but it ocured to me that much of my struggles could have been
mitigated if the relevant types had Show instances.

I am specifically talking about the types concerning type checking.
TypecheckedModule and everything below that.
I am aware that most of the types have an Outputable instance, but
there are two problems with that:

- 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)
- These instances are not intended to show the internal structure of a
  value, but rather a 'human readable' representation of a value.

My questions for you:

- Is there a reason that there are no derived 'Show' instances for most
  types?
- Would you accept a diff that adds these?

Thank you for your time.

-- 
Tom Sydney Kerckhove
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170318/a5e8b946/attachment.sig>

From rae at cs.brynmawr.edu  Sat Mar 18 13:11:17 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Sat, 18 Mar 2017 09:11:17 -0400
Subject: Why are there no Show instances for internal types
In-Reply-To: <20170318130348.GC25078@quintus.localdomain>
References: <20170318130348.GC25078@quintus.localdomain>
Message-ID: <03DC8ED0-D95A-4191-A840-76529E0E98D5@cs.brynmawr.edu>

My take is that we don't have these because they would slow down compilation times and add bloat. But enough people have asked for them (and, I can think of a few times when I would use them myself) that I think they should be added.

It is conceivable that we could make the instances only when DEBUG is on. That would, I believe, involve some unsavory CPP, and may not be worth it. What do others think?

Richard

> On Mar 18, 2017, at 9:03 AM, Tom Sydney Kerckhove <syd.kerckhove at gmail.com> wrote:
> 
> Dear GHC Devs,
> 
> I am trying to use GHC as a library but I'm having a lot of trouble with
> understanding what everything means.
> Up to now, I have been able to figure out what to do by reading the
> sources, but it ocured to me that much of my struggles could have been
> mitigated if the relevant types had Show instances.
> 
> I am specifically talking about the types concerning type checking.
> TypecheckedModule and everything below that.
> I am aware that most of the types have an Outputable instance, but
> there are two problems with that:
> 
> - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)
> - These instances are not intended to show the internal structure of a
>  value, but rather a 'human readable' representation of a value.
> 
> My questions for you:
> 
> - Is there a reason that there are no derived 'Show' instances for most
>  types?
> - Would you accept a diff that adds these?
> 
> Thank you for your time.
> 
> -- 
> Tom Sydney Kerckhove
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From eric at seidel.io  Sat Mar 18 16:32:55 2017
From: eric at seidel.io (Eric Seidel)
Date: Sat, 18 Mar 2017 09:32:55 -0700
Subject: Travis again over time
In-Reply-To: <CANma=H8e5738rJ+PGN9QM2FSKKjNx6EAmBYK7GHbJWsMSKaYzw@mail.gmail.com>
References: <1488657386.11972.3.camel@joachim-breitner.de>
 <1488728220.8321.0.camel@joachim-breitner.de>
 <1488893957.3556.4.camel@joachim-breitner.de>
 <1489079840.12255.1.camel@joachim-breitner.de>
 <CANma=H8e5738rJ+PGN9QM2FSKKjNx6EAmBYK7GHbJWsMSKaYzw@mail.gmail.com>
Message-ID: <1489854775.594528.915582496.16431279@webmail.messagingengine.com>

On Sat, Mar 18, 2017, at 05:36, Alan & Kim Zimmerman wrote:
> FYI, liquidhaskell switched from travis to circleci.com because of
> timeout
> problems.
> 
> It seems the time available is larger there.

IIRC CircleCI doesn't have an overall build timeout at all, just
(configurable) per-command timeouts.

From mail at joachim-breitner.de  Sat Mar 18 17:05:32 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 18 Mar 2017 13:05:32 -0400
Subject: PSA: perf.haskell.org/ghc temporarily out of order
In-Reply-To: <CADmwj46xvrEy4cX1M4bFi7oGD-Qw6x4NbyyVUDzLm0Uqr3s-gw@mail.gmail.com>
References: <1489608762.3047.8.camel@joachim-breitner.de>
 <87lgs6jjls.fsf@ben-laptop.smart-cactus.org>
 <CADmwj46xvrEy4cX1M4bFi7oGD-Qw6x4NbyyVUDzLm0Uqr3s-gw@mail.gmail.com>
Message-ID: <1489856732.12071.0.camel@joachim-breitner.de>

Hi,

correct. It seems that 'make boot' tries to compile all of nofib, even
those that are not to be run. So this ought to be revised.

Greetings,
Joachim

Am Samstag, den 18.03.2017, 01:56 -0400 schrieb Reid Barton:
> Don't know whether it is the same issue, but perf.haskell.org seems
> to
> still have not built anything for the past 3 days, according to
> https://github.com/nomeata/ghc-speed-logs/commits/master.
> 
> Regards,
> Reid Barton
> 
> On Wed, Mar 15, 2017 at 5:49 PM, Ben Gamari <ben at smart-cactus.org>
> wrote:
> > Joachim Breitner <mail at joachim-breitner.de> writes:
> > 
> > > Hi,
> > > 
> > > a recent change to nofib
> > > (https://phabricator.haskell.org/rNOFIB313812d319e009d698bc1a4d2e
> > > 8ac26d4dfe3c0a)
> > > broke the perf.haskell.org builder, so we won’t be getting perf
> > > warnings until that is fixed.
> > > 
> > 
> > I've pushed the michalt's fix. Thanks for the quick turnaround,
> > michalt!
> > 
> > Cheers,
> > 
> > - Ben
> > 
> > 
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > 
> 
> 
-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170318/5bda3b99/attachment.sig>

From michal.terepeta at gmail.com  Sat Mar 18 17:58:41 2017
From: michal.terepeta at gmail.com (Michal Terepeta)
Date: Sat, 18 Mar 2017 17:58:41 +0000
Subject: Stat too good
In-Reply-To: <DM2PR21MB00287BC411A0F38B802280B1AD390@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <DM2PR21MB00287BC411A0F38B802280B1AD390@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <CAEN7k7nsQSxrBerFhpCLvhFDJ9eWmACYnsiJ_LdjE75=RkimLQ@mail.gmail.com>

Just FYI: I'm on 64-bit Linux and don't see those failures (I just
validated at 763f43e6d3)

Cheers,
Michal

On Fri, Mar 17, 2017 at 6:49 PM Simon Peyton Jones via ghc-devs <
ghc-devs at haskell.org> wrote:

> Ben,
>
> I still get these four stat-too-good “failures” on 64-bit Linux.
>
> Unexpected stat failures:
>
>    /tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T13035.run  T13035
> [stat too good] (normal)
>
>    /tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T12425.run  T12425
> [stat too good] (optasm)
>
>    /tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T1969.run   T1969
> [stat too good] (normal)
>
>    /tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T9233.run   T9233
> [stat too good] (normal)
>
> Don’t you?
>
> Simon
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170318/c4bf28c6/attachment-0001.html>

From ezyang at mit.edu  Sat Mar 18 19:44:03 2017
From: ezyang at mit.edu (Edward Z. Yang)
Date: Sat, 18 Mar 2017 12:44:03 -0700
Subject: Why are there no Show instances for internal types
In-Reply-To: <20170318130348.GC25078@quintus.localdomain>
References: <20170318130348.GC25078@quintus.localdomain>
Message-ID: <1489866152-sup-6028@sabre>

We can't add Show instances for these types because many types
below them, e.g., Type, are cyclic, and would result in infinite
output.

Perhaps we can add a new type class which a) faithfully represents
the Haskell syntax, but b) can deal with cyclic data.  I think that's
something people would like (extra compilation time not withstanding).
But it sounds annoying to do since the deriving mechanism is not going
to help you.

Edward

Excerpts from Tom Sydney Kerckhove's message of 2017-03-18 14:03:48 +0100:
> Dear GHC Devs,
> 
> I am trying to use GHC as a library but I'm having a lot of trouble with
> understanding what everything means.
> Up to now, I have been able to figure out what to do by reading the
> sources, but it ocured to me that much of my struggles could have been
> mitigated if the relevant types had Show instances.
> 
> I am specifically talking about the types concerning type checking.
> TypecheckedModule and everything below that.
> I am aware that most of the types have an Outputable instance, but
> there are two problems with that:
> 
> - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)
> - These instances are not intended to show the internal structure of a
>   value, but rather a 'human readable' representation of a value.
> 
> My questions for you:
> 
> - Is there a reason that there are no derived 'Show' instances for most
>   types?
> - Would you accept a diff that adds these?
> 
> Thank you for your time.
> 

From alan.zimm at gmail.com  Sat Mar 18 19:47:29 2017
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Sat, 18 Mar 2017 21:47:29 +0200
Subject: Why are there no Show instances for internal types
In-Reply-To: <1489866152-sup-6028@sabre>
References: <20170318130348.GC25078@quintus.localdomain>
 <1489866152-sup-6028@sabre>
Message-ID: <CANma=H-c6H6Qk-y2iP_qscP+Qq72+qTy1aNciAkBsop68i4AaQ@mail.gmail.com>

And I guess it would be bad to use Show, but make custom instances for the
problematic types that did not loop?

Alan

On 18 Mar 2017 9:44 pm, "Edward Z. Yang" <ezyang at mit.edu> wrote:

> We can't add Show instances for these types because many types
> below them, e.g., Type, are cyclic, and would result in infinite
> output.
>
> Perhaps we can add a new type class which a) faithfully represents
> the Haskell syntax, but b) can deal with cyclic data.  I think that's
> something people would like (extra compilation time not withstanding).
> But it sounds annoying to do since the deriving mechanism is not going
> to help you.
>
> Edward
>
> Excerpts from Tom Sydney Kerckhove's message of 2017-03-18 14:03:48 +0100:
> > Dear GHC Devs,
> >
> > I am trying to use GHC as a library but I'm having a lot of trouble with
> > understanding what everything means.
> > Up to now, I have been able to figure out what to do by reading the
> > sources, but it ocured to me that much of my struggles could have been
> > mitigated if the relevant types had Show instances.
> >
> > I am specifically talking about the types concerning type checking.
> > TypecheckedModule and everything below that.
> > I am aware that most of the types have an Outputable instance, but
> > there are two problems with that:
> >
> > - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)
> > - These instances are not intended to show the internal structure of a
> >   value, but rather a 'human readable' representation of a value.
> >
> > My questions for you:
> >
> > - Is there a reason that there are no derived 'Show' instances for most
> >   types?
> > - Would you accept a diff that adds these?
> >
> > Thank you for your time.
> >
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170318/240ee03c/attachment.html>

From ben at smart-cactus.org  Sat Mar 18 20:13:52 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Sat, 18 Mar 2017 16:13:52 -0400
Subject: Why are there no Show instances for internal types
In-Reply-To: <20170318130348.GC25078@quintus.localdomain>
References: <20170318130348.GC25078@quintus.localdomain>
Message-ID: <D7822897-6EB9-403D-A132-9D5712B87443@smart-cactus.org>



On March 18, 2017 9:03:48 AM EDT, Tom Sydney Kerckhove <syd.kerckhove at gmail.com> wrote:

Snip.
>
>My questions for you:
>
>- Is there a reason that there are no derived 'Show' instances for most
>  types?

As Richard mentioned, we don't derive Show due to code size and compilation time concerns. Show in particular is rather expensive to derive and seeing as we already have Outputable I don't it would make sense to derive it by default. I would really like to avoid introducing more CPP into the code base for this particular problem.

One alternative which will work in many cases is to simply derive Show yourself using StandaloneDeriving. Does this help?

Cheers,

- Ben 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

From rahulmutt at gmail.com  Sat Mar 18 20:38:56 2017
From: rahulmutt at gmail.com (Rahul Muttineni)
Date: Sun, 19 Mar 2017 02:08:56 +0530
Subject: Why are there no Show instances for internal types
In-Reply-To: <1489866152-sup-6028@sabre>
References: <20170318130348.GC25078@quintus.localdomain>
 <1489866152-sup-6028@sabre>
Message-ID: <CANij+eSRCNOh5X1_kVayfisnpwhu+s58s6CfqfpO20mx2nGz9w@mail.gmail.com>

I think another way to go about this problem is to figure out an
alternative to baking in DynFlags to SDocContext (which I feel is the core
problem here). The only use of those DynFlags is via sdocWithDynFlags and
94 call sites use them.

- In the frontend, it's used to check for the presence of the flag (like
suppress module prefixes, etc.)
- In the code generator, it's used to get the word size, endianness, and
other platform specific stuff for platform-specific printing.
- Backpack-related stuff needed to get the package state
  - Used in exactly 2 cases: Outputable instances for ComponentId and
InstalledUnitId

>From what I observed with the majority of use cases, sdocWithDynFlags is
used to obviate the need for passing dflags to various ppr* functions,
which is a good idea since without it, we'd probably have to pass around
DynFlags to a whole lot more pure functions throughout the codebase.

So as others have said, Show instances are just not practical because
printing many of the GHC types is highly dependent on the platform and what
flags GHC was invoked with.

There are three solutions here:
1.) Figure out a subset of DynFlags (flags, platform details, package
state) and only allow those inside of SDocContext and extend SDocContext as
     new use cases come up. This is probably not practical as it would
require sweeping changes.
2.) Provide a stock set of DynFlags for the purpose of printing with
Outputable. It's easy to do for flags and platform details, but tricky to
do for package state. This seems to be the most reasonable solution if some
sane substitute for package state can be used.

Syd, can you tell us what kind of things you were trying to print out? You
can try to pass in unsafeGlobalDynFlags but it may not be what you want. It
gets written to on the initialisation of the GHC monad and after the
command line options are parsed (so everything will be properly initialised
except for package state).

Hope that helps,
Rahul

On Sun, Mar 19, 2017 at 1:14 AM, Edward Z. Yang <ezyang at mit.edu> wrote:

> We can't add Show instances for these types because many types
> below them, e.g., Type, are cyclic, and would result in infinite
> output.
>
> Perhaps we can add a new type class which a) faithfully represents
> the Haskell syntax, but b) can deal with cyclic data.  I think that's
> something people would like (extra compilation time not withstanding).
> But it sounds annoying to do since the deriving mechanism is not going
> to help you.
>
> Edward
>
> Excerpts from Tom Sydney Kerckhove's message of 2017-03-18 14:03:48 +0100:
> > Dear GHC Devs,
> >
> > I am trying to use GHC as a library but I'm having a lot of trouble with
> > understanding what everything means.
> > Up to now, I have been able to figure out what to do by reading the
> > sources, but it ocured to me that much of my struggles could have been
> > mitigated if the relevant types had Show instances.
> >
> > I am specifically talking about the types concerning type checking.
> > TypecheckedModule and everything below that.
> > I am aware that most of the types have an Outputable instance, but
> > there are two problems with that:
> >
> > - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)
> > - These instances are not intended to show the internal structure of a
> >   value, but rather a 'human readable' representation of a value.
> >
> > My questions for you:
> >
> > - Is there a reason that there are no derived 'Show' instances for most
> >   types?
> > - Would you accept a diff that adds these?
> >
> > Thank you for your time.
> >
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>



-- 
Rahul Muttineni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170319/f17412da/attachment.html>

From mail at joachim-breitner.de  Sat Mar 18 20:50:58 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 18 Mar 2017 16:50:58 -0400
Subject: Why are there no Show instances for internal types
In-Reply-To: <20170318130348.GC25078@quintus.localdomain>
References: <20170318130348.GC25078@quintus.localdomain>
Message-ID: <1489870258.12071.4.camel@joachim-breitner.de>

Am Samstag, den 18.03.2017, 14:03 +0100 schrieb Tom Sydney Kerckhove:
> 
> - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)


You can often get away with

showSDocUnsafe . ppr :: Outputable a => a -> String

Greetings,
Joachim
-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170318/ef5aa800/attachment-0001.sig>

From ben at smart-cactus.org  Sat Mar 18 21:19:22 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Sat, 18 Mar 2017 17:19:22 -0400
Subject: Why are there no Show instances for internal types
In-Reply-To: <CANij+eSRCNOh5X1_kVayfisnpwhu+s58s6CfqfpO20mx2nGz9w@mail.gmail.com>
References: <20170318130348.GC25078@quintus.localdomain>
 <1489866152-sup-6028@sabre>
 <CANij+eSRCNOh5X1_kVayfisnpwhu+s58s6CfqfpO20mx2nGz9w@mail.gmail.com>
Message-ID: <87y3w2i8px.fsf@ben-laptop.smart-cactus.org>

Rahul Muttineni <rahulmutt at gmail.com> writes:

> I think another way to go about this problem is to figure out an
> alternative to baking in DynFlags to SDocContext (which I feel is the core
> problem here). The only use of those DynFlags is via sdocWithDynFlags and
> 94 call sites use them.
>
Indeed, I would love to see this happen. This exact request is being
tracked as #10143.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170318/af74535f/attachment.sig>

From ezyang at mit.edu  Sat Mar 18 21:20:34 2017
From: ezyang at mit.edu (Edward Z. Yang)
Date: Sat, 18 Mar 2017 14:20:34 -0700
Subject: Why are there no Show instances for internal types
In-Reply-To: <CANij+eSRCNOh5X1_kVayfisnpwhu+s58s6CfqfpO20mx2nGz9w@mail.gmail.com>
References: <20170318130348.GC25078@quintus.localdomain>
 <1489866152-sup-6028@sabre>
 <CANij+eSRCNOh5X1_kVayfisnpwhu+s58s6CfqfpO20mx2nGz9w@mail.gmail.com>
Message-ID: <1489871893-sup-9336@sabre>

Hi Rahul,

This ticket may be of interest:

https://ghc.haskell.org/trac/ghc/ticket/10143

Edward

Excerpts from Rahul Muttineni's message of 2017-03-19 02:08:56 +0530:
> I think another way to go about this problem is to figure out an
> alternative to baking in DynFlags to SDocContext (which I feel is the core
> problem here). The only use of those DynFlags is via sdocWithDynFlags and
> 94 call sites use them.
> 
> - In the frontend, it's used to check for the presence of the flag (like
> suppress module prefixes, etc.)
> - In the code generator, it's used to get the word size, endianness, and
> other platform specific stuff for platform-specific printing.
> - Backpack-related stuff needed to get the package state
>   - Used in exactly 2 cases: Outputable instances for ComponentId and
> InstalledUnitId
> 
> From what I observed with the majority of use cases, sdocWithDynFlags is
> used to obviate the need for passing dflags to various ppr* functions,
> which is a good idea since without it, we'd probably have to pass around
> DynFlags to a whole lot more pure functions throughout the codebase.
> 
> So as others have said, Show instances are just not practical because
> printing many of the GHC types is highly dependent on the platform and what
> flags GHC was invoked with.
> 
> There are three solutions here:
> 1.) Figure out a subset of DynFlags (flags, platform details, package
> state) and only allow those inside of SDocContext and extend SDocContext as
>      new use cases come up. This is probably not practical as it would
> require sweeping changes.
> 2.) Provide a stock set of DynFlags for the purpose of printing with
> Outputable. It's easy to do for flags and platform details, but tricky to
> do for package state. This seems to be the most reasonable solution if some
> sane substitute for package state can be used.
> 
> Syd, can you tell us what kind of things you were trying to print out? You
> can try to pass in unsafeGlobalDynFlags but it may not be what you want. It
> gets written to on the initialisation of the GHC monad and after the
> command line options are parsed (so everything will be properly initialised
> except for package state).
> 
> Hope that helps,
> Rahul
> 
> On Sun, Mar 19, 2017 at 1:14 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
> 
> > We can't add Show instances for these types because many types
> > below them, e.g., Type, are cyclic, and would result in infinite
> > output.
> >
> > Perhaps we can add a new type class which a) faithfully represents
> > the Haskell syntax, but b) can deal with cyclic data.  I think that's
> > something people would like (extra compilation time not withstanding).
> > But it sounds annoying to do since the deriving mechanism is not going
> > to help you.
> >
> > Edward
> >
> > Excerpts from Tom Sydney Kerckhove's message of 2017-03-18 14:03:48 +0100:
> > > Dear GHC Devs,
> > >
> > > I am trying to use GHC as a library but I'm having a lot of trouble with
> > > understanding what everything means.
> > > Up to now, I have been able to figure out what to do by reading the
> > > sources, but it ocured to me that much of my struggles could have been
> > > mitigated if the relevant types had Show instances.
> > >
> > > I am specifically talking about the types concerning type checking.
> > > TypecheckedModule and everything below that.
> > > I am aware that most of the types have an Outputable instance, but
> > > there are two problems with that:
> > >
> > > - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)
> > > - These instances are not intended to show the internal structure of a
> > >   value, but rather a 'human readable' representation of a value.
> > >
> > > My questions for you:
> > >
> > > - Is there a reason that there are no derived 'Show' instances for most
> > >   types?
> > > - Would you accept a diff that adds these?
> > >
> > > Thank you for your time.
> > >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> 

From mle+hs at mega-nerd.com  Sat Mar 18 21:35:35 2017
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Sun, 19 Mar 2017 08:35:35 +1100
Subject: Compiling CMM tests with LLVM
Message-ID: <20170319083535.c4594b823448a267c5397996@mega-nerd.com>

Hi all,

I'm working on a minor change to CMM (#13442) and while writing the
tests realized that the CMM tests were only run with `-fasm` and not
with `-fllvm`. Furthermore other than running the test manually myself,
I could not figure out how to make it compile with LLVM.

My test (in my WIP local branch) is:

    testsuite/tests/codeGen/should_compile/T13442.cmm

and I updated the `all.T` in that same directory with the line:

    test('T13442', [cmm_src], compile, ['-dcmm-lint'])

Anyone have any clues as to how to make this compile with LLVM if
LLVM is available? I suspect it should probably be turned on for
the vast majority of the CMM tests.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From mle+hs at mega-nerd.com  Sat Mar 18 22:06:09 2017
From: mle+hs at mega-nerd.com (Erik de Castro Lopo)
Date: Sun, 19 Mar 2017 09:06:09 +1100
Subject: Compiling CMM tests with LLVM
In-Reply-To: <20170319083535.c4594b823448a267c5397996@mega-nerd.com>
References: <20170319083535.c4594b823448a267c5397996@mega-nerd.com>
Message-ID: <20170319090609.7d786d3f9b8c921507c3343c@mega-nerd.com>

Erik de Castro Lopo wrote:

> Hi all,
> 
> I'm working on a minor change to CMM (#13442) and while writing the
> tests realized that the CMM tests were only run with `-fasm` and not
> with `-fllvm`. Furthermore other than running the test manually myself,
> I could not figure out how to make it compile with LLVM.
> 
> My test (in my WIP local branch) is:
> 
>     testsuite/tests/codeGen/should_compile/T13442.cmm
> 
> and I updated the `all.T` in that same directory with the line:
> 
>     test('T13442', [cmm_src], compile, ['-dcmm-lint'])
> 
> Anyone have any clues as to how to make this compile with LLVM if
> LLVM is available? I suspect it should probably be turned on for
> the vast majority of the CMM tests.

Ok, I added the following function to `testlib.py`:

    def cmm_src_llvm( name, opts ):
        opts.only_ways = ['optllvm', 'llvm', 'debugllvm']
        opts.cmm_src = 1;

and changed my test set up to:

     test('T13442', [cmm_src, cmm_src_llvm], compile, ['-dcmm-lint'])

Would still be interested to know if this is the correct way and
if there is a better way.

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

From syd.kerckhove at gmail.com  Sat Mar 18 22:52:10 2017
From: syd.kerckhove at gmail.com (Tom Sydney Kerckhove)
Date: Sat, 18 Mar 2017 23:52:10 +0100
Subject: Why are there no Show instances for internal types
In-Reply-To: <CANij+eSRCNOh5X1_kVayfisnpwhu+s58s6CfqfpO20mx2nGz9w@mail.gmail.com>
References: <20170318130348.GC25078@quintus.localdomain>
 <1489866152-sup-6028@sabre>
 <CANij+eSRCNOh5X1_kVayfisnpwhu+s58s6CfqfpO20mx2nGz9w@mail.gmail.com>
Message-ID: <20170318225210.GH25078@quintus.localdomain>

On 19-03-17 02:08:56, Rahul Muttineni wrote:
> Syd, can you tell us what kind of things you were trying to print out?

Maybe I wasn't very clear.
I'm trying to visualise the internal structure of some of the
typechecker's output.
I specifically do NOT need to see the output of Outputable's functions.
They show the human-readibly version and not the internal structure.

Does that answer your question?
> Hope that helps,
> Rahul
> 
> On Sun, Mar 19, 2017 at 1:14 AM, Edward Z. Yang <ezyang at mit.edu> wrote:
> 
> > We can't add Show instances for these types because many types
> > below them, e.g., Type, are cyclic, and would result in infinite
> > output.
> >
> > Perhaps we can add a new type class which a) faithfully represents
> > the Haskell syntax, but b) can deal with cyclic data.  I think that's
> > something people would like (extra compilation time not withstanding).
> > But it sounds annoying to do since the deriving mechanism is not going
> > to help you.
> >
> > Edward
> >
> > Excerpts from Tom Sydney Kerckhove's message of 2017-03-18 14:03:48 +0100:
> > > Dear GHC Devs,
> > >
> > > I am trying to use GHC as a library but I'm having a lot of trouble with
> > > understanding what everything means.
> > > Up to now, I have been able to figure out what to do by reading the
> > > sources, but it ocured to me that much of my struggles could have been
> > > mitigated if the relevant types had Show instances.
> > >
> > > I am specifically talking about the types concerning type checking.
> > > TypecheckedModule and everything below that.
> > > I am aware that most of the types have an Outputable instance, but
> > > there are two problems with that:
> > >
> > > - 'Outputting' a value requires DynFlags. (yes, I know about pprTrace)
> > > - These instances are not intended to show the internal structure of a
> > >   value, but rather a 'human readable' representation of a value.
> > >
> > > My questions for you:
> > >
> > > - Is there a reason that there are no derived 'Show' instances for most
> > >   types?
> > > - Would you accept a diff that adds these?
> > >
> > > Thank you for your time.
> > >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
> 
> 
> 
> -- 
> Rahul Muttineni

-- 
Tom Sydney Kerckhove
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170318/e9f2d59a/attachment.sig>

From syd.kerckhove at gmail.com  Sat Mar 18 22:55:24 2017
From: syd.kerckhove at gmail.com (Tom Sydney Kerckhove)
Date: Sat, 18 Mar 2017 23:55:24 +0100
Subject: Why are there no Show instances for internal types
In-Reply-To: <D7822897-6EB9-403D-A132-9D5712B87443@smart-cactus.org>
References: <20170318130348.GC25078@quintus.localdomain>
 <D7822897-6EB9-403D-A132-9D5712B87443@smart-cactus.org>
Message-ID: <20170318225523.GI25078@quintus.localdomain>

On 18-03-17 16:13:52, Ben Gamari wrote:
> 
> 
> On March 18, 2017 9:03:48 AM EDT, Tom Sydney Kerckhove <syd.kerckhove at gmail.com> wrote:
> 
> Snip.
> >
> >My questions for you:
> >
> >- Is there a reason that there are no derived 'Show' instances for most
> >  types?
> 
> As Richard mentioned, we don't derive Show due to code size and compilation time concerns.

Okay.

> Show in particular is rather expensive to derive and seeing as we already have Outputable I don't it would make sense to derive it by default.

Show and Outputable have very different goals though.

> I would really like to avoid introducing more CPP into the code base for this particular problem.

Fair enough.

> One alternative which will work in many cases is to simply derive Show yourself using StandaloneDeriving. Does this help?

That doesn't work if some type doesn't have the constructors exposed.
I tried this already, and it would be a good solution if all
constructors were exposed, ...

> Cheers,
> 
> - Ben 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
Tom Sydney Kerckhove
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170318/5bfd88b6/attachment.sig>

From ben at well-typed.com  Sun Mar 19 00:23:10 2017
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 18 Mar 2017 20:23:10 -0400
Subject: Stat too good
In-Reply-To: <DM2PR21MB00287BC411A0F38B802280B1AD390@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <DM2PR21MB00287BC411A0F38B802280B1AD390@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <87tw6qi07l.fsf@ben-laptop.smart-cactus.org>

Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> writes:

> Ben,
> I still get these four stat-too-good "failures" on 64-bit Linux.
>
> Unexpected stat failures:
>
>    /tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T13035.run  T13035 [stat too good] (normal)
>
>    /tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T12425.run  T12425 [stat too good] (optasm)
>
>    /tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T1969.run   T1969 [stat too good] (normal)
>
>    /tmp/ghctest-ca0gfq/test   spaces/./perf/compiler/T9233.run   T9233
>    [stat too good] (normal)
>
> Don't you?

I'm not seeing anything like this at the moment but I have seen a great
deal of variability in testsuite results recently. In fact, I had to bump the
acceptance window size of T4029 as my local machine, Harbormaster, and
the OS X build bot differed by nearly 10% in max_bytes_used.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170318/bf0bb5b9/attachment-0001.sig>

From ben at smart-cactus.org  Sun Mar 19 00:24:50 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Sat, 18 Mar 2017 20:24:50 -0400
Subject: Why are there no Show instances for internal types
In-Reply-To: <20170318225210.GH25078@quintus.localdomain>
References: <20170318130348.GC25078@quintus.localdomain>
 <1489866152-sup-6028@sabre>
 <CANij+eSRCNOh5X1_kVayfisnpwhu+s58s6CfqfpO20mx2nGz9w@mail.gmail.com>
 <20170318225210.GH25078@quintus.localdomain>
Message-ID: <87shmai04t.fsf@ben-laptop.smart-cactus.org>

Tom Sydney Kerckhove <syd.kerckhove at gmail.com> writes:

> On 19-03-17 02:08:56, Rahul Muttineni wrote:
>> Syd, can you tell us what kind of things you were trying to print out?
>
> Maybe I wasn't very clear.
> I'm trying to visualise the internal structure of some of the
> typechecker's output.
> I specifically do NOT need to see the output of Outputable's functions.
> They show the human-readibly version and not the internal structure.
>
Indeed I am sympathetic to this request. In my time working on GHC I
have written raw several variants of `Type -> SDoc`, each exposing
various levels of detail. These are handy and can be a good way to gain
insight into the AST, but I feel like it is hard to come up with
something that is generally applicable; I find each time I need to
expose slightly different details about the internal structure of the
representation.

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170318/0dcf10a8/attachment.sig>

From rwbarton at gmail.com  Sun Mar 19 17:23:00 2017
From: rwbarton at gmail.com (Reid Barton)
Date: Sun, 19 Mar 2017 13:23:00 -0400
Subject: PSA: perf.haskell.org/ghc temporarily out of order
In-Reply-To: <1489856732.12071.0.camel@joachim-breitner.de>
References: <1489608762.3047.8.camel@joachim-breitner.de>
 <87lgs6jjls.fsf@ben-laptop.smart-cactus.org>
 <CADmwj46xvrEy4cX1M4bFi7oGD-Qw6x4NbyyVUDzLm0Uqr3s-gw@mail.gmail.com>
 <1489856732.12071.0.camel@joachim-breitner.de>
Message-ID: <CADmwj44kMQOnUiD0RxWtcSx59GO00bV4n=sjxLDicfwp0wY1aw@mail.gmail.com>

ght? On Sat, Mar 18, 2017 at 1:05 PM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
> correct. It seems that 'make boot' tries to compile all of nofib, even
> those that are not to be run. So this ought to be revised.

This appears to not actually be the case though, from local testing.
"make boot" never enters spectral/secretary, and it succeeds even
though it uses the inplace compiler for dependency generation.

Moreover even if `make -C nofib boot` was failing, there should be
`.broken` log files uploaded to
https://github.com/nomeata/ghc-speed-logs/, right? But even those are
missing. So something seems to be more seriously broken.

Regards,
Reid Barton

> Greetings,
> Joachim
>
> Am Samstag, den 18.03.2017, 01:56 -0400 schrieb Reid Barton:
>> Don't know whether it is the same issue, but perf.haskell.org seems
>> to
>> still have not built anything for the past 3 days, according to
>> https://github.com/nomeata/ghc-speed-logs/commits/master.
>>
>> Regards,
>> Reid Barton
>>
>> On Wed, Mar 15, 2017 at 5:49 PM, Ben Gamari <ben at smart-cactus.org>
>> wrote:
>> > Joachim Breitner <mail at joachim-breitner.de> writes:
>> >
>> > > Hi,
>> > >
>> > > a recent change to nofib
>> > > (https://phabricator.haskell.org/rNOFIB313812d319e009d698bc1a4d2e
>> > > 8ac26d4dfe3c0a)
>> > > broke the perf.haskell.org builder, so we won’t be getting perf
>> > > warnings until that is fixed.
>> > >
>> >
>> > I've pushed the michalt's fix. Thanks for the quick turnaround,
>> > michalt!
>> >
>> > Cheers,
>> >
>> > - Ben
>> >
>> >
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> >
>>
>>
> --
> Joachim “nomeata” Breitner
>   mail at joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From mail at joachim-breitner.de  Sun Mar 19 18:16:53 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 19 Mar 2017 14:16:53 -0400
Subject: PSA: perf.haskell.org/ghc temporarily out of order
In-Reply-To: <CADmwj44kMQOnUiD0RxWtcSx59GO00bV4n=sjxLDicfwp0wY1aw@mail.gmail.com>
References: <1489608762.3047.8.camel@joachim-breitner.de>
 <87lgs6jjls.fsf@ben-laptop.smart-cactus.org>
 <CADmwj46xvrEy4cX1M4bFi7oGD-Qw6x4NbyyVUDzLm0Uqr3s-gw@mail.gmail.com>
 <1489856732.12071.0.camel@joachim-breitner.de>
 <CADmwj44kMQOnUiD0RxWtcSx59GO00bV4n=sjxLDicfwp0wY1aw@mail.gmail.com>
Message-ID: <1489947413.31214.6.camel@joachim-breitner.de>

Hi,

Am Sonntag, den 19.03.2017, 13:23 -0400 schrieb Reid Barton:
> ght? On Sat, Mar 18, 2017 at 1:05 PM, Joachim Breitner
> > <mail at joachim-breitner.de> wrote:
> > Hi,
> > 
> > correct. It seems that 'make boot' tries to compile all of nofib, even
> > those that are not to be run. So this ought to be revised.
> 
> This appears to not actually be the case though, from local testing.
> "make boot" never enters spectral/secretary, and it succeeds even
> though it uses the inplace compiler for dependency generation.
> 
> Moreover even if `make -C nofib boot` was failing, there should be
> `.broken` log files uploaded to
> https://github.com/nomeata/ghc-speed-logs/, right? But even those are
> missing. So something seems to be more seriously broken.

indeed, last upload 5 days ago. Let me have a look…


It is busy building d357f526582e3c4cd4fbda5d73695fc81121b69a which
seems to hang in the test suite. Killed it, hopefully that fixes it.
Even if it does, it will take a while to catch up.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170319/6352494e/attachment.sig>

From zhiwudazhanjiangshi at gmail.com  Mon Mar 20 01:29:14 2017
From: zhiwudazhanjiangshi at gmail.com (yi lu)
Date: Mon, 20 Mar 2017 09:29:14 +0800
Subject: A possible bug in ghc documentation
Message-ID: <CAKcmqqxK=9dFuQzZh8a7-LB6g4CZdNbnh=o23brT3+AjUc15gg@mail.gmail.com>

Hi all,

Sorry to bother. I'm not sure if this is the right place to post this, but
I find a possible bug in ghc documentation.

http://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/flags.html#language-options

^In 7.6.12, -XDeriveGeneric
<http://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/glasgow_exts.html#ghc-flag--XDeriveGeneric>
 appears twice.

If it is a bug, please fix. Thanks.




Yi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170320/cda24a53/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture d’écran 2017-03-20 à 8.35.31 AM.png
Type: image/png
Size: 79398 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170320/cda24a53/attachment-0001.png>

From rwbarton at gmail.com  Mon Mar 20 01:37:43 2017
From: rwbarton at gmail.com (Reid Barton)
Date: Sun, 19 Mar 2017 21:37:43 -0400
Subject: PSA: perf.haskell.org/ghc temporarily out of order
In-Reply-To: <1489947413.31214.6.camel@joachim-breitner.de>
References: <1489608762.3047.8.camel@joachim-breitner.de>
 <87lgs6jjls.fsf@ben-laptop.smart-cactus.org>
 <CADmwj46xvrEy4cX1M4bFi7oGD-Qw6x4NbyyVUDzLm0Uqr3s-gw@mail.gmail.com>
 <1489856732.12071.0.camel@joachim-breitner.de>
 <CADmwj44kMQOnUiD0RxWtcSx59GO00bV4n=sjxLDicfwp0wY1aw@mail.gmail.com>
 <1489947413.31214.6.camel@joachim-breitner.de>
Message-ID: <CADmwj47ELG=jDFFH_goZDEJSJ14WCefr5whSaNLhjHwtziGUfQ@mail.gmail.com>

On Sun, Mar 19, 2017 at 2:16 PM, Joachim Breitner
<mail at joachim-breitner.de> wrote:
> Hi,
>
> Am Sonntag, den 19.03.2017, 13:23 -0400 schrieb Reid Barton:
>> ght? On Sat, Mar 18, 2017 at 1:05 PM, Joachim Breitner
>> > <mail at joachim-breitner.de> wrote:
>> > Hi,
>> >
>> > correct. It seems that 'make boot' tries to compile all of nofib, even
>> > those that are not to be run. So this ought to be revised.
>>
>> This appears to not actually be the case though, from local testing.
>> "make boot" never enters spectral/secretary, and it succeeds even
>> though it uses the inplace compiler for dependency generation.
>>
>> Moreover even if `make -C nofib boot` was failing, there should be
>> `.broken` log files uploaded to
>> https://github.com/nomeata/ghc-speed-logs/, right? But even those are
>> missing. So something seems to be more seriously broken.
>
> indeed, last upload 5 days ago. Let me have a look…
>
>
> It is busy building d357f526582e3c4cd4fbda5d73695fc81121b69a which
> seems to hang in the test suite. Killed it, hopefully that fixes it.

Thanks, it has started building again, and has almost gotten to the
commit which will fix nofib.

> Even if it does, it will take a while to catch up.

Yep, that's why I was eager to get it working again. At least the
commits where nofib was broken build a bit faster :)

Regards,
Reid Barton

> Greetings,
> Joachim
>
> --
> Joachim “nomeata” Breitner
>   mail at joachim-breitner.de • https://www.joachim-breitner.de/
>   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
>   Debian Developer: nomeata at debian.org
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

From mail at joachim-breitner.de  Mon Mar 20 01:42:31 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 19 Mar 2017 21:42:31 -0400
Subject: PSA: perf.haskell.org/ghc temporarily out of order
In-Reply-To: <CADmwj47ELG=jDFFH_goZDEJSJ14WCefr5whSaNLhjHwtziGUfQ@mail.gmail.com>
References: <1489608762.3047.8.camel@joachim-breitner.de>
 <87lgs6jjls.fsf@ben-laptop.smart-cactus.org>
 <CADmwj46xvrEy4cX1M4bFi7oGD-Qw6x4NbyyVUDzLm0Uqr3s-gw@mail.gmail.com>
 <1489856732.12071.0.camel@joachim-breitner.de>
 <CADmwj44kMQOnUiD0RxWtcSx59GO00bV4n=sjxLDicfwp0wY1aw@mail.gmail.com>
 <1489947413.31214.6.camel@joachim-breitner.de>
 <CADmwj47ELG=jDFFH_goZDEJSJ14WCefr5whSaNLhjHwtziGUfQ@mail.gmail.com>
Message-ID: <1489974151.32065.1.camel@joachim-breitner.de>

Hi,

Am Sonntag, den 19.03.2017, 21:37 -0400 schrieb Reid Barton:
> > Even if it does, it will take a while to catch up.
> 
> Yep, that's why I was eager to get it working again. At least the
> commits where nofib was broken build a bit faster :)

if you look at
https://github.com/nomeata/gipeda/blob/master/ghc/run-speed.sh#L60
you can see that my runner script in in principle capable of fixing
some commits in retrospect. We’ll see if it is worth it for this
incident. The fix would probably simply consist of rm-rf’ing the
spectra/secretary folder, right?

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170319/8a52ebd1/attachment.sig>

From omeragacan at gmail.com  Mon Mar 20 06:42:07 2017
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Mon, 20 Mar 2017 09:42:07 +0300
Subject: A possible bug in ghc documentation
In-Reply-To: <CAKcmqqxK=9dFuQzZh8a7-LB6g4CZdNbnh=o23brT3+AjUc15gg@mail.gmail.com>
References: <CAKcmqqxK=9dFuQzZh8a7-LB6g4CZdNbnh=o23brT3+AjUc15gg@mail.gmail.com>
Message-ID: <CAMQQO3kgtdT4=OSJCYLiMA=PXvNnCsfUJ6oTvq+6zhYVMKZYng@mail.gmail.com>

Hi Yi,

Thanks for reporting. I just fixed this.

Ömer

2017-03-20 4:29 GMT+03:00 yi lu <zhiwudazhanjiangshi at gmail.com>:

> Hi all,
>
> Sorry to bother. I'm not sure if this is the right place to post this, but
> I find a possible bug in ghc documentation.
>
> http://downloads.haskell.org/~ghc/8.0.2/docs/html/users_
> guide/flags.html#language-options
>
> ^In 7.6.12, -XDeriveGeneric
> <http://downloads.haskell.org/~ghc/8.0.2/docs/html/users_guide/glasgow_exts.html#ghc-flag--XDeriveGeneric>
>  appears twice.
>
> If it is a bug, please fix. Thanks.
>
>
>
>
> Yi
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170320/f3450025/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture d’écran 2017-03-20 à 8.35.31 AM.png
Type: image/png
Size: 79398 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170320/f3450025/attachment-0001.png>

From simonpj at microsoft.com  Mon Mar 20 12:51:13 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 20 Mar 2017 12:51:13 +0000
Subject: Why are there no Show instances for internal types
In-Reply-To: <20170318225523.GI25078@quintus.localdomain>
References: <20170318130348.GC25078@quintus.localdomain>
 <D7822897-6EB9-403D-A132-9D5712B87443@smart-cactus.org>
 <20170318225523.GI25078@quintus.localdomain>
Message-ID: <DM2PR21MB002806A86CA7941C2CC95381AD3A0@DM2PR21MB0028.namprd21.prod.outlook.com>


| > >- Is there a reason that there are no derived 'Show' instances for
| > >most types?
| >
| > As Richard mentioned, we don't derive Show due to code size and
| compilation time concerns.

| > Show in particular is rather expensive to derive and seeing as we
| already have Outputable I don't it would make sense to derive it by
| default.
| 
| Show and Outputable have very different goals though.

Really? What's wrong with using Outputable, plus, as Joachim says, 

	showSDocUnsafe . ppr :: Outputable a => a -> String

Maybe you want to really really see the precise data constructors used.  But for the most part the Outputable instance tells you that, but much more legibly.

Simon

From mail at joachim-breitner.de  Mon Mar 20 14:45:43 2017
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 20 Mar 2017 10:45:43 -0400
Subject: Why are there no Show instances for internal types
In-Reply-To: <DM2PR21MB002806A86CA7941C2CC95381AD3A0@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <20170318130348.GC25078@quintus.localdomain>
 <D7822897-6EB9-403D-A132-9D5712B87443@smart-cactus.org>
 <20170318225523.GI25078@quintus.localdomain>
 <DM2PR21MB002806A86CA7941C2CC95381AD3A0@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <1490021143.1380.1.camel@joachim-breitner.de>

Hi,

Am Montag, den 20.03.2017, 12:51 +0000 schrieb Simon Peyton Jones via ghc-devs:
> Show and Outputable have very different goals though.
> 
> Really? What's wrong with using Outputable, plus, as Joachim says, 
> 
> 	showSDocUnsafe . ppr :: Outputable a => a -> String
> 
> Maybe you want to really really see the precise data constructors
> used.  But for the most part the Outputable instance tells you that,
> but much more legibly.

and if using Outputable is a bit annoying sometimes (e.g. I found it
hard to get the IdInfo of an Id that is not part of a binder, if I
recall correctly, because the default instance does not include that
info, and the pretty printer for “id with idinfo” is not exported),
well, we can always improve that by adding a few more helpful functions
to Outputable.

Greetings,
Joachim

-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170320/09bccc2d/attachment.sig>

From matthewtpickering at gmail.com  Mon Mar 20 15:52:27 2017
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Mon, 20 Mar 2017 15:52:27 +0000
Subject: SPECIALISE INLINE pragma
Message-ID: <CALuQ0m8ViQdzNRGmz0zpzNwsqVkvXdynmtY4TvGuHQ2KCHrJJQ@mail.gmail.com>

The user guide says that "you can make GHC diverge by using SPECIALISE
INLINE on an ordinarily-recursive function."

Does anyone know the ticket or technique which causes this to happen?

https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#specialize-inline


On the same topic, I also wrote a blog post simply explaining the
essential things to know
about the inliner and specialiser as I don't think they are generally
appreciated. Comments welcome!

http://mpickering.github.io/posts/2017-03-20-inlining-and-specialisation.html

Matt

From mikolaj at well-typed.com  Mon Mar 20 23:40:46 2017
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Tue, 21 Mar 2017 00:40:46 +0100
Subject: SPECIALISE INLINE pragma
In-Reply-To: <CALuQ0m8ViQdzNRGmz0zpzNwsqVkvXdynmtY4TvGuHQ2KCHrJJQ@mail.gmail.com>
References: <CALuQ0m8ViQdzNRGmz0zpzNwsqVkvXdynmtY4TvGuHQ2KCHrJJQ@mail.gmail.com>
Message-ID: <CAHFo2up+LAcrNqyoqr5eh-H6rz99FdZJsa5mxuBG4mSsNYRr+g@mail.gmail.com>

> On the same topic, I also wrote a blog post simply explaining the
> essential things to know
> about the inliner and specialiser as I don't think they are generally
> appreciated. Comments welcome!
>
> http://mpickering.github.io/posts/2017-03-20-inlining-and-specialisation.html

LGTM. I'd propose to link to this from GHC manual.

I didn't know the bit about INLINE being ignored
on a loop-breaker with no warning and no way of changing
the loop-breaker. That probably explains puzzling
and counter-intuitive results of some alternative layouts
of INLINEs in the computation-intensive parts of my code,
at least since the time I provide unfoldings for all functions
and so discounts don't help GHC in picking the intended loop-breaker.
And I don't think this ignoring of the programmer's intent
wrt INLINE is documented in the usual places.

From david.feuer at gmail.com  Tue Mar 21 20:34:20 2017
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 21 Mar 2017 16:34:20 -0400
Subject: DeriveFoldable treatment of tuples is surprising
Message-ID: <CAMgWh9s4iMX9BHpM+p0JUJKqrte7ED940nxZAcbcNpYmf1en5w@mail.gmail.com>

This seems much too weird:

*> :set -XDeriveFoldable
*> data Foo a = Foo ((a,a),a) deriving Foldable
*> length ((1,1),1)
1
*> length $ Foo ((1,1),1)
3

I've opened Trac #13465 [*] for this. As I write there, I think the
right thing is to refuse to derive Foldable for a type whose Foldable
instance would currently fold over components of a tuple other than
the last one.

I could go either way on Traversable instances. One could argue that
since all relevant components *must* be traversed, we should just go
ahead and do that. Or one could argue that we should be consistent
with Foldable and refuse to derive it.

What do you all think?

[*] https://ghc.haskell.org/trac/ghc/ticket/13465

From david.feuer at gmail.com  Tue Mar 21 21:11:39 2017
From: david.feuer at gmail.com (David Feuer)
Date: Tue, 21 Mar 2017 17:11:39 -0400
Subject: DeriveFoldable treatment of tuples is surprising
In-Reply-To: <CACN--9Dh7zTbBS_dV7cq_zh_fSBm_z3ZO+NVLRS1u-318G8DiA@mail.gmail.com>
References: <CAMgWh9s4iMX9BHpM+p0JUJKqrte7ED940nxZAcbcNpYmf1en5w@mail.gmail.com>
 <CACN--9Dh7zTbBS_dV7cq_zh_fSBm_z3ZO+NVLRS1u-318G8DiA@mail.gmail.com>
Message-ID: <CAMgWh9se54x6TgC=2jWgXrRZ=iDh-PABDbc1nV7dHw6m8AQCQg@mail.gmail.com>

The point is that there are two reasonable ways to do it, and the
deriving mechanism, as a rule, does not make choices between
reasonable alternatives.

On Tue, Mar 21, 2017 at 5:05 PM, Jake McArthur <jake.mcarthur at gmail.com> wrote:
> I think it's a question of what one considers consistent. Is it more
> consistent to treat tuples as transparent and consider every component with
> type `a`, or is it more consistent to treat tuples as opaque and reuse the
> existing Foldable instance for tuples even if it might cause a compile time
> error?
>
>
> On Tue, Mar 21, 2017, 4:34 PM David Feuer <david.feuer at gmail.com> wrote:
>>
>> This seems much too weird:
>>
>> *> :set -XDeriveFoldable
>> *> data Foo a = Foo ((a,a),a) deriving Foldable
>> *> length ((1,1),1)
>> 1
>> *> length $ Foo ((1,1),1)
>> 3
>>
>> I've opened Trac #13465 [*] for this. As I write there, I think the
>> right thing is to refuse to derive Foldable for a type whose Foldable
>> instance would currently fold over components of a tuple other than
>> the last one.
>>
>> I could go either way on Traversable instances. One could argue that
>> since all relevant components *must* be traversed, we should just go
>> ahead and do that. Or one could argue that we should be consistent
>> with Foldable and refuse to derive it.
>>
>> What do you all think?
>>
>> [*] https://ghc.haskell.org/trac/ghc/ticket/13465
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

From oleg.grenrus at iki.fi  Tue Mar 21 21:27:57 2017
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Tue, 21 Mar 2017 23:27:57 +0200
Subject: DeriveFoldable treatment of tuples is surprising
In-Reply-To: <CAMgWh9se54x6TgC=2jWgXrRZ=iDh-PABDbc1nV7dHw6m8AQCQg@mail.gmail.com>
References: <CAMgWh9s4iMX9BHpM+p0JUJKqrte7ED940nxZAcbcNpYmf1en5w@mail.gmail.com>
 <CACN--9Dh7zTbBS_dV7cq_zh_fSBm_z3ZO+NVLRS1u-318G8DiA@mail.gmail.com>
 <CAMgWh9se54x6TgC=2jWgXrRZ=iDh-PABDbc1nV7dHw6m8AQCQg@mail.gmail.com>
Message-ID: <985c934f-532d-594e-aaf9-87542d1b5c16@iki.fi>

For `Traversable` one have to `traverse` over everything:

    traverse @Foo = forall f. Applicative f => (a -> f b) -> Foo a -> f
(Foo b)

    ~= .... -> ((a,a), a) -> f ((b,b), b)

And thus the same behavior for `Foldable`.

You should define:

    data Foo b a = Foo ((b,b), a) deriving Foldable

- Oleg

On 21.03.2017 23:11, David Feuer wrote:
> The point is that there are two reasonable ways to do it, and the
> deriving mechanism, as a rule, does not make choices between
> reasonable alternatives.
>
> On Tue, Mar 21, 2017 at 5:05 PM, Jake McArthur <jake.mcarthur at gmail.com> wrote:
>> I think it's a question of what one considers consistent. Is it more
>> consistent to treat tuples as transparent and consider every component with
>> type `a`, or is it more consistent to treat tuples as opaque and reuse the
>> existing Foldable instance for tuples even if it might cause a compile time
>> error?
>>
>>
>> On Tue, Mar 21, 2017, 4:34 PM David Feuer <david.feuer at gmail.com> wrote:
>>> This seems much too weird:
>>>
>>> *> :set -XDeriveFoldable
>>> *> data Foo a = Foo ((a,a),a) deriving Foldable
>>> *> length ((1,1),1)
>>> 1
>>> *> length $ Foo ((1,1),1)
>>> 3
>>>
>>> I've opened Trac #13465 [*] for this. As I write there, I think the
>>> right thing is to refuse to derive Foldable for a type whose Foldable
>>> instance would currently fold over components of a tuple other than
>>> the last one.
>>>
>>> I could go either way on Traversable instances. One could argue that
>>> since all relevant components *must* be traversed, we should just go
>>> ahead and do that. Or one could argue that we should be consistent
>>> with Foldable and refuse to derive it.
>>>
>>> What do you all think?
>>>
>>> [*] https://ghc.haskell.org/trac/ghc/ticket/13465
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170321/68237016/attachment.sig>

From ekmett at gmail.com  Tue Mar 21 21:29:20 2017
From: ekmett at gmail.com (Edward Kmett)
Date: Tue, 21 Mar 2017 17:29:20 -0400
Subject: DeriveFoldable treatment of tuples is surprising
In-Reply-To: <CAMgWh9se54x6TgC=2jWgXrRZ=iDh-PABDbc1nV7dHw6m8AQCQg@mail.gmail.com>
References: <CAMgWh9s4iMX9BHpM+p0JUJKqrte7ED940nxZAcbcNpYmf1en5w@mail.gmail.com>
 <CACN--9Dh7zTbBS_dV7cq_zh_fSBm_z3ZO+NVLRS1u-318G8DiA@mail.gmail.com>
 <CAMgWh9se54x6TgC=2jWgXrRZ=iDh-PABDbc1nV7dHw6m8AQCQg@mail.gmail.com>
Message-ID: <CAJumaK_FmnvPBy2hmnGojcTX8KPBhezQamDT-8WzKjwtOBwzXA@mail.gmail.com>

As I recall, Richard Eisenberg has been pushing, off and on, for us to get
a better vocabulary to specify "how" something is derived, via
DeriveAnyClass, generalized newtype deriving, DeriveFoldable, etc.

In general I think the current behavior is the least surprising as it
"walks all the a's it can" and is the only definition compatible with
further extension with Traversable. Right now there are no instances
provided by base that violate the "walk all the a's" intuition and there is
a fair bit of user code for things like vector types that do things like

newtype V3 a = V3 (a,a,a,a)

replacing that with a data type isn't without cost because now converting
back and forth between that and a tuple could no longer be done for zero
cost with coercions. This style of code is more common among the
ML-turned-haskeller crowd, whom -- in my experience -- tend to think of it
as just giving the constructor paren around its arguments rather than as a
tuple.

Destroying Foldable for that and making working code not work just for
users to have to manually specify multiple tedious instances that should be
easily derivable shouldn't be a thing we do lightly. DeriveFunctor doesn't
consider that functors involved may be contravariant either. DeriveFoo
generally does something that is a best effort.

I'm more inclined to leave it on the list of things that DeriveFoo does
differently than GND, and as yet another argument pushing us to find a
better vocabulary for talking about deriving.

-Edward


On Tue, Mar 21, 2017 at 5:11 PM, David Feuer <david.feuer at gmail.com> wrote:

> The point is that there are two reasonable ways to do it, and the
> deriving mechanism, as a rule, does not make choices between
> reasonable alternatives.
>
> On Tue, Mar 21, 2017 at 5:05 PM, Jake McArthur <jake.mcarthur at gmail.com>
> wrote:
> > I think it's a question of what one considers consistent. Is it more
> > consistent to treat tuples as transparent and consider every component
> with
> > type `a`, or is it more consistent to treat tuples as opaque and reuse
> the
> > existing Foldable instance for tuples even if it might cause a compile
> time
> > error?
> >
> >
> > On Tue, Mar 21, 2017, 4:34 PM David Feuer <david.feuer at gmail.com> wrote:
> >>
> >> This seems much too weird:
> >>
> >> *> :set -XDeriveFoldable
> >> *> data Foo a = Foo ((a,a),a) deriving Foldable
> >> *> length ((1,1),1)
> >> 1
> >> *> length $ Foo ((1,1),1)
> >> 3
> >>
> >> I've opened Trac #13465 [*] for this. As I write there, I think the
> >> right thing is to refuse to derive Foldable for a type whose Foldable
> >> instance would currently fold over components of a tuple other than
> >> the last one.
> >>
> >> I could go either way on Traversable instances. One could argue that
> >> since all relevant components *must* be traversed, we should just go
> >> ahead and do that. Or one could argue that we should be consistent
> >> with Foldable and refuse to derive it.
> >>
> >> What do you all think?
> >>
> >> [*] https://ghc.haskell.org/trac/ghc/ticket/13465
> >> _______________________________________________
> >> Glasgow-haskell-users mailing list
> >> Glasgow-haskell-users at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170321/4f8d6623/attachment.html>

From svenpanne at gmail.com  Wed Mar 22 08:12:27 2017
From: svenpanne at gmail.com (Sven Panne)
Date: Wed, 22 Mar 2017 09:12:27 +0100
Subject: DeriveFoldable treatment of tuples is surprising
In-Reply-To: <CAJumaK_FmnvPBy2hmnGojcTX8KPBhezQamDT-8WzKjwtOBwzXA@mail.gmail.com>
References: <CAMgWh9s4iMX9BHpM+p0JUJKqrte7ED940nxZAcbcNpYmf1en5w@mail.gmail.com>
 <CACN--9Dh7zTbBS_dV7cq_zh_fSBm_z3ZO+NVLRS1u-318G8DiA@mail.gmail.com>
 <CAMgWh9se54x6TgC=2jWgXrRZ=iDh-PABDbc1nV7dHw6m8AQCQg@mail.gmail.com>
 <CAJumaK_FmnvPBy2hmnGojcTX8KPBhezQamDT-8WzKjwtOBwzXA@mail.gmail.com>
Message-ID: <CANBN=muVJmyKGY9OPz+9QcAxxu6=so_EuUgK=7q1dqwV-yvMeA@mail.gmail.com>

2017-03-21 22:29 GMT+01:00 Edward Kmett <ekmett at gmail.com>:

> [... In general I think the current behavior is the least surprising as it
> "walks all the a's it can" and is the only definition compatible with
> further extension with Traversable. [...]
>

OTOH, the current behavior contradicts my intuition that wrapping a type
into data/newtype plus using the deriving machinery is basically a no-op
(modulo bottoms etc.). When I e.g. wrap a type t, I would be very surprised
if the Eq/Ord instances of the wrapped type would behave differently than
the one on t. I know that this is very handwavy argument, but I think the
current behavior is *very* surprising.

Somehow the current behavior seems to be incompatible with the FTP, where
pairs are given a special treatment (if that't the right/intuitive choice
is a completely different topic, though).

Given the fact that "deriving Foldable" is quite old and therefore hard to
change, I would at least suggest a big, fat warning in the documentation,
including various examples where intuition and implementation do not
necessarily meet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170322/e085a643/attachment-0001.html>

From simonpj at microsoft.com  Wed Mar 22 10:50:23 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 22 Mar 2017 10:50:23 +0000
Subject: SPECIALISE INLINE pragma
In-Reply-To: <CALuQ0m8ViQdzNRGmz0zpzNwsqVkvXdynmtY4TvGuHQ2KCHrJJQ@mail.gmail.com>
References: <CALuQ0m8ViQdzNRGmz0zpzNwsqVkvXdynmtY4TvGuHQ2KCHrJJQ@mail.gmail.com>
Message-ID: <DM2PR21MB00288624291530C72CC2D1BAAD3C0@DM2PR21MB0028.namprd21.prod.outlook.com>

|  On the same topic, I also wrote a blog post simply explaining the
|  essential things to know about the inliner and specialiser as I don't
|  think they are generally appreciated. Comments welcome!
|  
|  http://mpickering.github.io/posts/2017-03-20-inlining-and-
|  specialisation.html

Fantastic work Matthew.

Might you put in the "Collaborative documentation" section of the Haskell wiki?  https://wiki.haskell.org/GHC

That way others could help edit/maintain/extend it.  I have quite a few suggestions, but most are easier just to execute than to send you suggested deltas.


|  The user guide says that "you can make GHC diverge by using SPECIALISE
|  INLINE on an ordinarily-recursive function."

Suppose you have

f x = ...(f [x])...

Now I think SPECIALISE INLINE might go on for ever, making more and more specialised copies.  At least I think that's it.  Making a concrete example and putting that in the manual would be great.

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Matthew Pickering
|  Sent: 20 March 2017 15:52
|  To: GHC developers <ghc-devs at haskell.org>
|  Subject: SPECIALISE INLINE pragma
|  
|  The user guide says that "you can make GHC diverge by using SPECIALISE
|  INLINE on an ordinarily-recursive function."
|  
|  Does anyone know the ticket or technique which causes this to happen?
|  
|  https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgo
|  w_exts.html#specialize-inline
|  
|  
|  
|  Matt
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From simonpj at microsoft.com  Wed Mar 22 10:52:10 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Wed, 22 Mar 2017 10:52:10 +0000
Subject: SPECIALISE INLINE pragma
In-Reply-To: <CAHFo2up+LAcrNqyoqr5eh-H6rz99FdZJsa5mxuBG4mSsNYRr+g@mail.gmail.com>
References: <CALuQ0m8ViQdzNRGmz0zpzNwsqVkvXdynmtY4TvGuHQ2KCHrJJQ@mail.gmail.com>
 <CAHFo2up+LAcrNqyoqr5eh-H6rz99FdZJsa5mxuBG4mSsNYRr+g@mail.gmail.com>
Message-ID: <DM2PR21MB002881A5D850DE034A9274E7AD3C0@DM2PR21MB0028.namprd21.prod.outlook.com>

|  I didn't know the bit about INLINE being ignored on a loop-breaker
|  with no warning and no way of changing the loop-breaker.

GHC tries hard NOT to choose an INLINE function as a loop breaker.  But if you write

f x = if ... then 0 else (f x')
{-# INLINE f #-}

then the only possible loop breaker is 'f', so GHC has to choose it. 

What else would you suggest?  What puzzling behaviour do you have in mind?

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Mikolaj Konarski
|  Sent: 20 March 2017 23:41
|  To: Matthew Pickering <matthewtpickering at gmail.com>
|  Cc: GHC developers <ghc-devs at haskell.org>
|  Subject: Re: SPECIALISE INLINE pragma
|  
|  > On the same topic, I also wrote a blog post simply explaining the
|  > essential things to know about the inliner and specialiser as I
|  don't
|  > think they are generally appreciated. Comments welcome!
|  >
|  > http://mpickering.github.io/posts/2017-03-20-inlining-and-
|  specialisati
|  > on.html
|  
|  LGTM. I'd propose to link to this from GHC manual.
|  
|  I didn't know the bit about INLINE being ignored on a loop-breaker
|  with no warning and no way of changing the loop-breaker. That probably
|  explains puzzling and counter-intuitive results of some alternative
|  layouts of INLINEs in the computation-intensive parts of my code, at
|  least since the time I provide unfoldings for all functions and so
|  discounts don't help GHC in picking the intended loop-breaker.
|  And I don't think this ignoring of the programmer's intent wrt INLINE
|  is documented in the usual places.
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From matthewtpickering at gmail.com  Wed Mar 22 11:02:35 2017
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Wed, 22 Mar 2017 11:02:35 +0000
Subject: SPECIALISE INLINE pragma
In-Reply-To: <DM2PR21MB00288624291530C72CC2D1BAAD3C0@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <CALuQ0m8ViQdzNRGmz0zpzNwsqVkvXdynmtY4TvGuHQ2KCHrJJQ@mail.gmail.com>
 <DM2PR21MB00288624291530C72CC2D1BAAD3C0@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <CALuQ0m_wxveP78Z6-Zgnse6b3xHbGkuyfRRkAstt55FYbfNhEg@mail.gmail.com>

Thanks Simon.

I made a page for it here - https://wiki.haskell.org/Inlining_and_Specialisation

Matt

On Wed, Mar 22, 2017 at 10:50 AM, Simon Peyton Jones
<simonpj at microsoft.com> wrote:
> |  On the same topic, I also wrote a blog post simply explaining the
> |  essential things to know about the inliner and specialiser as I don't
> |  think they are generally appreciated. Comments welcome!
> |
> |  http://mpickering.github.io/posts/2017-03-20-inlining-and-
> |  specialisation.html
>
> Fantastic work Matthew.
>
> Might you put in the "Collaborative documentation" section of the Haskell wiki?  https://wiki.haskell.org/GHC
>
> That way others could help edit/maintain/extend it.  I have quite a few suggestions, but most are easier just to execute than to send you suggested deltas.
>
>
> |  The user guide says that "you can make GHC diverge by using SPECIALISE
> |  INLINE on an ordinarily-recursive function."
>
> Suppose you have
>
> f x = ...(f [x])...
>
> Now I think SPECIALISE INLINE might go on for ever, making more and more specialised copies.  At least I think that's it.  Making a concrete example and putting that in the manual would be great.
>
> Simon
>
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> |  Matthew Pickering
> |  Sent: 20 March 2017 15:52
> |  To: GHC developers <ghc-devs at haskell.org>
> |  Subject: SPECIALISE INLINE pragma
> |
> |  The user guide says that "you can make GHC diverge by using SPECIALISE
> |  INLINE on an ordinarily-recursive function."
> |
> |  Does anyone know the ticket or technique which causes this to happen?
> |
> |  https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgo
> |  w_exts.html#specialize-inline
> |
> |
> |
> |  Matt
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From fryguybob at gmail.com  Wed Mar 22 12:50:16 2017
From: fryguybob at gmail.com (Ryan Yates)
Date: Wed, 22 Mar 2017 08:50:16 -0400
Subject: DeriveFoldable treatment of tuples is surprising
In-Reply-To: <CANBN=muVJmyKGY9OPz+9QcAxxu6=so_EuUgK=7q1dqwV-yvMeA@mail.gmail.com>
References: <CAMgWh9s4iMX9BHpM+p0JUJKqrte7ED940nxZAcbcNpYmf1en5w@mail.gmail.com>
 <CACN--9Dh7zTbBS_dV7cq_zh_fSBm_z3ZO+NVLRS1u-318G8DiA@mail.gmail.com>
 <CAMgWh9se54x6TgC=2jWgXrRZ=iDh-PABDbc1nV7dHw6m8AQCQg@mail.gmail.com>
 <CAJumaK_FmnvPBy2hmnGojcTX8KPBhezQamDT-8WzKjwtOBwzXA@mail.gmail.com>
 <CANBN=muVJmyKGY9OPz+9QcAxxu6=so_EuUgK=7q1dqwV-yvMeA@mail.gmail.com>
Message-ID: <CAO27hRoRfF6cieZ2bDzQahK+-hMiKt5i1exzawwKS_B_JG7Q9Q@mail.gmail.com>

On Wed, Mar 22, 2017 at 4:12 AM, Sven Panne <svenpanne at gmail.com> wrote:

> 2017-03-21 22:29 GMT+01:00 Edward Kmett <ekmett at gmail.com>:
>
>> [... In general I think the current behavior is the least surprising as
>> it "walks all the a's it can" and is the only definition compatible with
>> further extension with Traversable. [...]
>>
>
> OTOH, the current behavior contradicts my intuition that wrapping a type
> into data/newtype plus using the deriving machinery is basically a no-op
> (modulo bottoms etc.). When I e.g. wrap a type t, I would be very surprised
> if the Eq/Ord instances of the wrapped type would behave differently than
> the one on t. I know that this is very handwavy argument, but I think the
> current behavior is *very* surprising.
>
> Somehow the current behavior seems to be incompatible with the FTP, where
> pairs are given a special treatment (if that't the right/intuitive choice
> is a completely different topic, though).
>

I'm not sure what you mean by "pairs are given a special treatment".
Tuples are given the only possible treatment:

data (,) a b = (a,b)

The b is the only place to fold over with a Foldable or change with a
Functor instance.  When things are monomorphic there are more options and
that leads to the least surprising, fold over all the options for:

data Pair a = Pair a a

or

data X a = X (a,a)

The (a,a) here is most certainly not the same thing as (a,b).  There is
something that is a bit surprising to me in that DerivingFoldable will not
a user declared data type for pair with two arguments:

> data Pair a = Pair a a deriving (Functor, Foldable, Show)
> data X a = X (Pair a) deriving (Functor, Foldable, Show)
> length (X (Pair 1 2))
2
> data Tup a b  = Tup a b deriving (Functor, Foldable, Show)
> data Y a = Y (Tup a a) deriving (Functor, Show)

<interactive>:10:34: error:
    • Can't make a derived instance of ‘Functor Y’:
        Constructor ‘Y’ must use the type variable only as the last
argument of a data type
    • In the data declaration for ‘Y’
> data Y a = Y (Tup a a) deriving (Foldable, Show)

<interactive>:11:34: error:
    • Can't make a derived instance of ‘Foldable Y’:
        Constructor ‘Y’ must use the type variable only as the last
argument of a data type
    • In the data declaration for ‘Y’
> data Y a = Y (Tup a a) deriving (Foldable, Show)

But it is happy to do just that with (a,a).


Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170322/6f109936/attachment.html>

From ryan.gl.scott at gmail.com  Wed Mar 22 13:47:32 2017
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Wed, 22 Mar 2017 09:47:32 -0400
Subject: DeriveFoldable treatment of tuples is surprising
Message-ID: <CADdQpRBk38zfptVZvsYLSDibeHOtUfvpG5tgpGanqaeWdCandA@mail.gmail.com>

I believe what Sven was saying is not that the Foldable instance for tuples
are given "special treatment" (which is arguably an orthogonal discussion),
but rather that -XDeriveFoldable special-cases tuples, which is certainly
true.

As Edward noted, there is one possible justification for this behavior
w.r.t. things like newtype V3 a = V3 (a, a, a) deriving Foldable. But to be
honest, I find this justification tenuous at best, given the confusion it
causes when explaining how DeriveFunctor/DeriveFoldable/DeriveTraversable
work to newcomers. Removing this special case would not only be simple, but
it would also lead to a more consistent story overall.

I would be curious to know how much code in the wild is actually taking
advantage of a trick like newtype V3 a = V3 (a, a, a) deriving Foldable. If
the breakage isn't terrible, then I propose we just rip off this wart.

(This is basically a rehash of the thoughts I left at
https://ghc.haskell.org/trac/ghc/ticket/13465#comment:3)

Ryan S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170322/8c0c4146/attachment.html>

From fryguybob at gmail.com  Wed Mar 22 13:54:03 2017
From: fryguybob at gmail.com (Ryan Yates)
Date: Wed, 22 Mar 2017 09:54:03 -0400
Subject: DeriveFoldable treatment of tuples is surprising
In-Reply-To: <CADdQpRBk38zfptVZvsYLSDibeHOtUfvpG5tgpGanqaeWdCandA@mail.gmail.com>
References: <CADdQpRBk38zfptVZvsYLSDibeHOtUfvpG5tgpGanqaeWdCandA@mail.gmail.com>
Message-ID: <CAO27hRpwOr+OwJnrPG38wrfD8JtnUFuQdsc2ChySbFW2rDRXAQ@mail.gmail.com>

Thanks for the clarification!

Ryan

On Wed, Mar 22, 2017 at 9:47 AM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:

> I believe what Sven was saying is not that the Foldable instance for
> tuples are given "special treatment" (which is arguably an orthogonal
> discussion), but rather that -XDeriveFoldable special-cases tuples, which
> is certainly true.
>
> As Edward noted, there is one possible justification for this behavior
> w.r.t. things like newtype V3 a = V3 (a, a, a) deriving Foldable. But to be
> honest, I find this justification tenuous at best, given the confusion it
> causes when explaining how DeriveFunctor/DeriveFoldable/DeriveTraversable
> work to newcomers. Removing this special case would not only be simple, but
> it would also lead to a more consistent story overall.
>
> I would be curious to know how much code in the wild is actually taking
> advantage of a trick like newtype V3 a = V3 (a, a, a) deriving Foldable. If
> the breakage isn't terrible, then I propose we just rip off this wart.
>
> (This is basically a rehash of the thoughts I left at
> https://ghc.haskell.org/trac/ghc/ticket/13465#comment:3)
>
> Ryan S.
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170322/0580d8ed/attachment.html>

From michal.terepeta at gmail.com  Wed Mar 22 18:44:53 2017
From: michal.terepeta at gmail.com (Michal Terepeta)
Date: Wed, 22 Mar 2017 18:44:53 +0000
Subject: FYI: removing `fibon`
In-Reply-To: <CAChsM3T1TbWUtrCGuL6t72z+gbuTK71nJ9eqfZxweLk8nScaDg@mail.gmail.com>
References: <CAEN7k7m7VCeyV9E5HOy-Vzzx0wzEPeAxrpvHiKu7TNowEFf9Yg@mail.gmail.com>
 <CAChsM3T1TbWUtrCGuL6t72z+gbuTK71nJ9eqfZxweLk8nScaDg@mail.gmail.com>
Message-ID: <CAEN7k7mxGV5WfeCKeSdxq56A8Huc_4fA6ZnYhG5NyJps1oUtkQ@mail.gmail.com>

Ok, thanks Gracjan!

Ben, could I ask you to pull from:
https://github.com/michalt/nofib/tree/fibon
(https://github.com/michalt/nofib.git branch `fibon`)
Or if you prefer Phab, let me know if there's some magic incantation
to make it work with this patch (`arc` currently crashes for me)

Thanks,
Michal

On Tue, Mar 14, 2017 at 9:32 PM Gracjan Polak <gracjanpolak at gmail.com>
wrote:

> I'm not working on it and do not plan to start again.
>
> Looks like fibon never worked and wasn't used for anything, so it should
> be removed. Still it would make sense to replace this code with something
> used as part of normal nofib test cases.
>
> 2017-03-14 19:59 GMT+01:00 Michal Terepeta <michal.terepeta at gmail.com>:
>
> Hi all,
>
> I wanted to remove `fibon` (from `nofib`) - it's broken, abandoned
> upstream (no commits in 5 years) and I'm not aware of anyone using it
> or working on it. At this point I don't think it makes sense to try to
> revive it - I'd prefer putting the time/effort into getting a few new
> benchmarks.
>
> There were already discussions about removing it in
> https://ghc.haskell.org/trac/ghc/ticket/11501
>
> If someone is actually working on getting it to work again, please
> shout!
>
> Thanks,
> Michal
>
> PS. I've tried uploading the patch to Phab, but I think it's just too
> large (arc is crashing). So I've uploaded it to github:
> https://github.com/michalt/nofib/tree/fibon
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170322/fe29e361/attachment-0001.html>

From ryan.gl.scott at gmail.com  Thu Mar 23 15:15:08 2017
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Thu, 23 Mar 2017 11:15:08 -0400
Subject: Polymorphism over unboxed tuples
Message-ID: <CADdQpRAwA29XGmXBwbf2MeOujAg1mqMfzSStufvJUiNJT1c9Zg@mail.gmail.com>

Section 4.2 of the paper Levity Polymorphism [1] makes a bold claim
about polymorphism for unboxed tuples:

  Note that this format respects the computational irrelevance of
nesting of unboxed tuples. For example, these three types all have the
same kind, here written PFP for short:

  type PFP = TYPE '[PtrRep, FloatRep, PtrRep]
  (# Int, (# Float#, Bool #) #)        :: PFP
  (# Int, Float#, Bool #)              :: PFP
  (# (# Int, (# #) #), Float#, Bool #) :: PFP

But in GHC, that isn't the case! Here's proof of it from a recent GHCi session:

  GHCi, version 8.3.20170322: http://www.haskell.org/ghc/  :? for help
  λ> :set -XUnboxedTuples -XMagicHash
  λ> import GHC.Exts
  λ> :kind (# Int, (# Float#, Bool #) #)
  (# Int, (# Float#, Bool #) #) :: TYPE
                                     ('TupleRep '['LiftedRep,
'TupleRep '['FloatRep, 'LiftedRep]])
  λ> :kind (# Int, Float#, Bool #)
  (# Int, Float#, Bool #) :: TYPE
                               ('TupleRep '['LiftedRep, 'FloatRep,
'LiftedRep])
  λ> :kind (# (# Int, (# #) #), Float#, Bool #)
  (# (# Int, (# #) #), Float#, Bool #) :: TYPE
                                            ('TupleRep
                                               '['TupleRep
'['LiftedRep, 'TupleRep '[]], 'FloatRep,
                                                 'LiftedRep])

As you can see, each of these different nestings of unboxed tuples
yields different kinds, so they most certainly do *not* uphold the
property claimed in the paper.

Is this a bug? Or is there some reason that GHC implemented it differently?

Ryan S.
-----
[1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/levity-1.pdf

From rae at cs.brynmawr.edu  Thu Mar 23 16:19:04 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Thu, 23 Mar 2017 12:19:04 -0400
Subject: Polymorphism over unboxed tuples
In-Reply-To: <CADdQpRAwA29XGmXBwbf2MeOujAg1mqMfzSStufvJUiNJT1c9Zg@mail.gmail.com>
References: <CADdQpRAwA29XGmXBwbf2MeOujAg1mqMfzSStufvJUiNJT1c9Zg@mail.gmail.com>
Message-ID: <EBCEE629-8DFE-490A-A8E7-1A3EFE6E501C@cs.brynmawr.edu>

This was a design choice in implementing, and one that is open for revision (but not for 8.2).

The key property is this:
 (*) Two types with different representations must have different kinds.

Note that (*) does not stipulate what happens with two types with the same representation, such as (# Int, (# Bool #) #) and (# Double, Char #). We decided it was simpler to have unboxed tuples with the same representation but different nestings to have different kinds. Part of the complication with what’s proposed in the paper is that the kind of unboxed tuple type constructors become more complicated. For example, we would have

(#,#) :: forall (r1 :: [UnaryRep]) (r2 :: [UnaryRep]). TYPE r1 -> TYPE r2 -> TYPE (TupleRep (Concat ‘[r1, r2]))

where Concat is a type family that does type-level list concatenation. This would work. But would it have type inference consequences? (You would be unable to infer the constituent kinds from the result kind.) I doubt anyone would notice.

The next problem comes when thinking about unboxed sums, though. To implement unboxed sums (unmentioned in the paper) along similar lines, you would need to include the quite-complicated algorithm for figuring out the concrete representation of a sum from its types. For example, (# (# Int, Int# #) | (# Word#, Int# #) #) takes up only 4 words in memory: 1 each for the tag, the pointer to the Int, the Word#, and the Int#. Note that the slot for the Int# is shared between the disjuncts! We can’t share other slots because the GC properties for an Int are different than for a Word#. But we also don’t take up 5 slots, repeating the Int#. The algorithm to figure this out is thus somewhat involved.

If we wanted two unboxed sums with the same representations to have the same kind, we would need to implement this algorithm in type families. It’s doable, surely, but nothing I want to contemplate. And, worse, it would expose this algorithm to users, who might start to depend on it in their polymorphism. What if we decide to change it? Then the type families change and users’ code breaks. Ich.

Of course, we could use precise kinds for tuples (Concat isn’t hard and isn’t likely to change) and imprecise kinds for sums. There’s nothing wrong with such a system. But until a user appears (maybe you!) asking for the precise kinds, it seems premature to commit ourselves to that mode.

Richard

> On Mar 23, 2017, at 11:15 AM, Ryan Scott <ryan.gl.scott at gmail.com> wrote:
> 
> Section 4.2 of the paper Levity Polymorphism [1] makes a bold claim
> about polymorphism for unboxed tuples:
> 
>  Note that this format respects the computational irrelevance of
> nesting of unboxed tuples. For example, these three types all have the
> same kind, here written PFP for short:
> 
>  type PFP = TYPE '[PtrRep, FloatRep, PtrRep]
>  (# Int, (# Float#, Bool #) #)        :: PFP
>  (# Int, Float#, Bool #)              :: PFP
>  (# (# Int, (# #) #), Float#, Bool #) :: PFP
> 
> But in GHC, that isn't the case! Here's proof of it from a recent GHCi session:
> 
>  GHCi, version 8.3.20170322: http://www.haskell.org/ghc/  :? for help
>  λ> :set -XUnboxedTuples -XMagicHash
>  λ> import GHC.Exts
>  λ> :kind (# Int, (# Float#, Bool #) #)
>  (# Int, (# Float#, Bool #) #) :: TYPE
>                                     ('TupleRep '['LiftedRep,
> 'TupleRep '['FloatRep, 'LiftedRep]])
>  λ> :kind (# Int, Float#, Bool #)
>  (# Int, Float#, Bool #) :: TYPE
>                               ('TupleRep '['LiftedRep, 'FloatRep,
> 'LiftedRep])
>  λ> :kind (# (# Int, (# #) #), Float#, Bool #)
>  (# (# Int, (# #) #), Float#, Bool #) :: TYPE
>                                            ('TupleRep
>                                               '['TupleRep
> '['LiftedRep, 'TupleRep '[]], 'FloatRep,
>                                                 'LiftedRep])
> 
> As you can see, each of these different nestings of unboxed tuples
> yields different kinds, so they most certainly do *not* uphold the
> property claimed in the paper.
> 
> Is this a bug? Or is there some reason that GHC implemented it differently?
> 
> Ryan S.
> -----
> [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/levity-1.pdf
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From mikolaj at well-typed.com  Thu Mar 23 21:14:54 2017
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Thu, 23 Mar 2017 22:14:54 +0100
Subject: SPECIALISE INLINE pragma
In-Reply-To: <DM2PR21MB002881A5D850DE034A9274E7AD3C0@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <CALuQ0m8ViQdzNRGmz0zpzNwsqVkvXdynmtY4TvGuHQ2KCHrJJQ@mail.gmail.com>
 <CAHFo2up+LAcrNqyoqr5eh-H6rz99FdZJsa5mxuBG4mSsNYRr+g@mail.gmail.com>
 <DM2PR21MB002881A5D850DE034A9274E7AD3C0@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <CAHFo2uq+=bAXJfBahcE2ctJW+g_BskGJ26_gdjjThbbuD0yYQg@mail.gmail.com>

> GHC tries hard NOT to choose an INLINE function as a loop breaker.  But if you write
>
> f x = if ... then 0 else (f x')
> {-# INLINE f #-}
>
> then the only possible loop breaker is 'f', so GHC has to choose it.

Indeed.

> What else would you suggest?

A warning would be very welcome. Given that the debugging
compiler emits one, perhaps it's not too difficult to add.

Apart of that, if the heuristics is based not on INLINE pragmas,
but on available unfoldings, as Matthew suggests in his wiki article,
I'd propose to fix that, see the case below.

> What puzzling behaviour do you have in mind?

I can't reconstruct it now, but I was profiling as set of mutually
recursive functions, with -fexpose-all-unfoldings (so GHC could not
decide based on available unfoldings) and INLINE on only some
of them (I don't remember if the others had NOINLINE or nothing).
I had an impression some of the INLINEs where ignored and that
the loop breaker was not at the place I was forcing, but the impression
was based only on comparison of runtimes of different variants,
not on inspecting core. A warning would really help next time
to let me catch a concrete example to post.

From omeragacan at gmail.com  Fri Mar 24 06:05:55 2017
From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=)
Date: Fri, 24 Mar 2017 09:05:55 +0300
Subject: Slow validate failures
Message-ID: <CAMQQO3=F4D9mU36mnxcx6xjkyyggn5Z+pfTwnWE5=f=_=ToCTg@mail.gmail.com>

Hi all,

I have a patch that effects profiling code and I realized neither `./validate
--fast` nor `./validate` test the "prof" way so I tried `./validate --slow`. I
saw that even on a clean branch I get 250 unexpected failures and 6 unexpected
passes. I had a quick look at logs. Most of the failures seem to be in these
formats:

-
    Compile failed (exit code 1) errors were:
    T6005a.hs:1:1: fatal:
        Cannot load -prof objects when GHC is built with -dynamic
        To fix this, either:
          (1) Use -fexternal-interpreter, or
          (2) Build the program twice: once with -dynamic, and then
              with -prof using -osuf to set a different object file suffix.

-
    Compile failed (exit code 1) errors were:

    T5984_Lib.hs:3:8: error:
        Could not find module ‘Prelude’
        Perhaps you haven't installed the "p_dyn" libraries for
package ‘base-4.10.0.0’?
        Use -v to see a list of the files searched for.

    T5984_Lib.hs:5:1: error:
        Could not find module ‘Language.Haskell.TH’
        Perhaps you haven't installed the "p_dyn" libraries for
package ‘template-haskell-2.12.0.0’?
        Use -v to see a list of the files searched for.

But there are also some serious-looking failures, like

    =====> hpc_fork(hpc) 5717 of 5834 [6, 245, 0]
    ...
    +++ "/tmp/ghctest-yrj0el9g/test
spaces/../../libraries/ghc-compact/tests/compact_share.run/compact_share.run.stdout.normalised"
2017-03-24 00:38:02.486282332 +0300
    @@ -1,4 +1,4 @@
     275599
    -3801088
    +6291456
     275599
    -2228224
    +3506176

So it seems at this point there's basically no realiable way to test profiling
changes. I was wondering if someone here know anything about these. If anyone's
interested, I pushed test output of `./validate --slow` here: (9.2M file)
https://gist.githubusercontent.com/osa1/7cbcc8303f1e213a10accf0bcd9b5ab2/raw/75371245bba2918f4ec97675abea9af661c77b25/gistfile1.txt

Ömer

From simonpj at microsoft.com  Fri Mar 24 13:14:38 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Fri, 24 Mar 2017 13:14:38 +0000
Subject: Polymorphism over unboxed tuples
In-Reply-To: <EBCEE629-8DFE-490A-A8E7-1A3EFE6E501C@cs.brynmawr.edu>
References: <CADdQpRAwA29XGmXBwbf2MeOujAg1mqMfzSStufvJUiNJT1c9Zg@mail.gmail.com>
 <EBCEE629-8DFE-490A-A8E7-1A3EFE6E501C@cs.brynmawr.edu>
Message-ID: <DM2PR21MB002894AE1F92EFBECC37E72EAD3E0@DM2PR21MB0028.namprd21.prod.outlook.com>

All true.  But perhaps the paper should articulate this thinking?

Simon

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Richard Eisenberg
|  Sent: 23 March 2017 16:19
|  To: Ryan Scott <ryan.gl.scott at gmail.com>
|  Cc: GHC developers <ghc-devs at haskell.org>
|  Subject: Re: Polymorphism over unboxed tuples
|  
|  This was a design choice in implementing, and one that is open for
|  revision (but not for 8.2).
|  
|  The key property is this:
|   (*) Two types with different representations must have different
|  kinds.
|  
|  Note that (*) does not stipulate what happens with two types with the
|  same representation, such as (# Int, (# Bool #) #) and (# Double, Char
|  #). We decided it was simpler to have unboxed tuples with the same
|  representation but different nestings to have different kinds. Part of
|  the complication with what’s proposed in the paper is that the kind of
|  unboxed tuple type constructors become more complicated. For example,
|  we would have
|  
|  (#,#) :: forall (r1 :: [UnaryRep]) (r2 :: [UnaryRep]). TYPE r1 -> TYPE
|  r2 -> TYPE (TupleRep (Concat ‘[r1, r2]))
|  
|  where Concat is a type family that does type-level list concatenation.
|  This would work. But would it have type inference consequences? (You
|  would be unable to infer the constituent kinds from the result kind.)
|  I doubt anyone would notice.
|  
|  The next problem comes when thinking about unboxed sums, though. To
|  implement unboxed sums (unmentioned in the paper) along similar lines,
|  you would need to include the quite-complicated algorithm for figuring
|  out the concrete representation of a sum from its types. For example,
|  (# (# Int, Int# #) | (# Word#, Int# #) #) takes up only 4 words in
|  memory: 1 each for the tag, the pointer to the Int, the Word#, and the
|  Int#. Note that the slot for the Int# is shared between the disjuncts!
|  We can’t share other slots because the GC properties for an Int are
|  different than for a Word#. But we also don’t take up 5 slots,
|  repeating the Int#. The algorithm to figure this out is thus somewhat
|  involved.
|  
|  If we wanted two unboxed sums with the same representations to have
|  the same kind, we would need to implement this algorithm in type
|  families. It’s doable, surely, but nothing I want to contemplate. And,
|  worse, it would expose this algorithm to users, who might start to
|  depend on it in their polymorphism. What if we decide to change it?
|  Then the type families change and users’ code breaks. Ich.
|  
|  Of course, we could use precise kinds for tuples (Concat isn’t hard
|  and isn’t likely to change) and imprecise kinds for sums. There’s
|  nothing wrong with such a system. But until a user appears (maybe
|  you!) asking for the precise kinds, it seems premature to commit
|  ourselves to that mode.
|  
|  Richard
|  
|  > On Mar 23, 2017, at 11:15 AM, Ryan Scott <ryan.gl.scott at gmail.com>
|  wrote:
|  >
|  > Section 4.2 of the paper Levity Polymorphism [1] makes a bold claim
|  > about polymorphism for unboxed tuples:
|  >
|  >  Note that this format respects the computational irrelevance of
|  > nesting of unboxed tuples. For example, these three types all have
|  the
|  > same kind, here written PFP for short:
|  >
|  >  type PFP = TYPE '[PtrRep, FloatRep, PtrRep]
|  >  (# Int, (# Float#, Bool #) #)        :: PFP
|  >  (# Int, Float#, Bool #)              :: PFP
|  >  (# (# Int, (# #) #), Float#, Bool #) :: PFP
|  >
|  > But in GHC, that isn't the case! Here's proof of it from a recent
|  GHCi session:
|  >
|  >  GHCi, version 8.3.20170322: http://www.haskell.org/ghc/  :? for
|  help
|  > λ> :set -XUnboxedTuples -XMagicHash  λ> import GHC.Exts  λ> :kind (#
|  > Int, (# Float#, Bool #) #)  (# Int, (# Float#, Bool #) #) :: TYPE
|  >                                     ('TupleRep '['LiftedRep,
|  'TupleRep
|  > '['FloatRep, 'LiftedRep]])  λ> :kind (# Int, Float#, Bool #)  (#
|  Int,
|  > Float#, Bool #) :: TYPE
|  >                               ('TupleRep '['LiftedRep, 'FloatRep,
|  > 'LiftedRep])
|  >  λ> :kind (# (# Int, (# #) #), Float#, Bool #)  (# (# Int, (# #) #),
|  > Float#, Bool #) :: TYPE
|  >                                            ('TupleRep
|  >                                               '['TupleRep
|  > '['LiftedRep, 'TupleRep '[]], 'FloatRep,
|  >                                                 'LiftedRep])
|  >
|  > As you can see, each of these different nestings of unboxed tuples
|  > yields different kinds, so they most certainly do *not* uphold the
|  > property claimed in the paper.
|  >
|  > Is this a bug? Or is there some reason that GHC implemented it
|  differently?
|  >
|  > Ryan S.
|  > -----
|  > [1]
|  > https://www.microsoft.com/en-us/research/wp-
|  content/uploads/2016/11/le
|  > vity-1.pdf _______________________________________________
|  > ghc-devs mailing list
|  > ghc-devs at haskell.org
|  > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
|  
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From rae at cs.brynmawr.edu  Sat Mar 25 02:44:34 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Fri, 24 Mar 2017 22:44:34 -0400
Subject: Polymorphism over unboxed tuples
In-Reply-To: <DM2PR21MB002894AE1F92EFBECC37E72EAD3E0@DM2PR21MB0028.namprd21.prod.outlook.com>
References: <CADdQpRAwA29XGmXBwbf2MeOujAg1mqMfzSStufvJUiNJT1c9Zg@mail.gmail.com>
 <EBCEE629-8DFE-490A-A8E7-1A3EFE6E501C@cs.brynmawr.edu>
 <DM2PR21MB002894AE1F92EFBECC37E72EAD3E0@DM2PR21MB0028.namprd21.prod.outlook.com>
Message-ID: <E1CDE5A2-EB1F-4E8F-8C79-8CA4B872864A@cs.brynmawr.edu>


> On Mar 24, 2017, at 9:14 AM, Simon Peyton Jones <simonpj at microsoft.com> wrote:
> 
> All true.  But perhaps the paper should articulate this thinking?

I'm OK with adding an appendix with this reasoning. I think it would clutter the paper itself to put this all there.

Richard

> 
> Simon
> 
> |  -----Original Message-----
> |  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
> |  Richard Eisenberg
> |  Sent: 23 March 2017 16:19
> |  To: Ryan Scott <ryan.gl.scott at gmail.com>
> |  Cc: GHC developers <ghc-devs at haskell.org>
> |  Subject: Re: Polymorphism over unboxed tuples
> |  
> |  This was a design choice in implementing, and one that is open for
> |  revision (but not for 8.2).
> |  
> |  The key property is this:
> |   (*) Two types with different representations must have different
> |  kinds.
> |  
> |  Note that (*) does not stipulate what happens with two types with the
> |  same representation, such as (# Int, (# Bool #) #) and (# Double, Char
> |  #). We decided it was simpler to have unboxed tuples with the same
> |  representation but different nestings to have different kinds. Part of
> |  the complication with what’s proposed in the paper is that the kind of
> |  unboxed tuple type constructors become more complicated. For example,
> |  we would have
> |  
> |  (#,#) :: forall (r1 :: [UnaryRep]) (r2 :: [UnaryRep]). TYPE r1 -> TYPE
> |  r2 -> TYPE (TupleRep (Concat ‘[r1, r2]))
> |  
> |  where Concat is a type family that does type-level list concatenation.
> |  This would work. But would it have type inference consequences? (You
> |  would be unable to infer the constituent kinds from the result kind.)
> |  I doubt anyone would notice.
> |  
> |  The next problem comes when thinking about unboxed sums, though. To
> |  implement unboxed sums (unmentioned in the paper) along similar lines,
> |  you would need to include the quite-complicated algorithm for figuring
> |  out the concrete representation of a sum from its types. For example,
> |  (# (# Int, Int# #) | (# Word#, Int# #) #) takes up only 4 words in
> |  memory: 1 each for the tag, the pointer to the Int, the Word#, and the
> |  Int#. Note that the slot for the Int# is shared between the disjuncts!
> |  We can’t share other slots because the GC properties for an Int are
> |  different than for a Word#. But we also don’t take up 5 slots,
> |  repeating the Int#. The algorithm to figure this out is thus somewhat
> |  involved.
> |  
> |  If we wanted two unboxed sums with the same representations to have
> |  the same kind, we would need to implement this algorithm in type
> |  families. It’s doable, surely, but nothing I want to contemplate. And,
> |  worse, it would expose this algorithm to users, who might start to
> |  depend on it in their polymorphism. What if we decide to change it?
> |  Then the type families change and users’ code breaks. Ich.
> |  
> |  Of course, we could use precise kinds for tuples (Concat isn’t hard
> |  and isn’t likely to change) and imprecise kinds for sums. There’s
> |  nothing wrong with such a system. But until a user appears (maybe
> |  you!) asking for the precise kinds, it seems premature to commit
> |  ourselves to that mode.
> |  
> |  Richard
> |  
> |  > On Mar 23, 2017, at 11:15 AM, Ryan Scott <ryan.gl.scott at gmail.com>
> |  wrote:
> |  >
> |  > Section 4.2 of the paper Levity Polymorphism [1] makes a bold claim
> |  > about polymorphism for unboxed tuples:
> |  >
> |  >  Note that this format respects the computational irrelevance of
> |  > nesting of unboxed tuples. For example, these three types all have
> |  the
> |  > same kind, here written PFP for short:
> |  >
> |  >  type PFP = TYPE '[PtrRep, FloatRep, PtrRep]
> |  >  (# Int, (# Float#, Bool #) #)        :: PFP
> |  >  (# Int, Float#, Bool #)              :: PFP
> |  >  (# (# Int, (# #) #), Float#, Bool #) :: PFP
> |  >
> |  > But in GHC, that isn't the case! Here's proof of it from a recent
> |  GHCi session:
> |  >
> |  >  GHCi, version 8.3.20170322: http://www.haskell.org/ghc/  :? for
> |  help
> |  > λ> :set -XUnboxedTuples -XMagicHash  λ> import GHC.Exts  λ> :kind (#
> |  > Int, (# Float#, Bool #) #)  (# Int, (# Float#, Bool #) #) :: TYPE
> |  >                                     ('TupleRep '['LiftedRep,
> |  'TupleRep
> |  > '['FloatRep, 'LiftedRep]])  λ> :kind (# Int, Float#, Bool #)  (#
> |  Int,
> |  > Float#, Bool #) :: TYPE
> |  >                               ('TupleRep '['LiftedRep, 'FloatRep,
> |  > 'LiftedRep])
> |  >  λ> :kind (# (# Int, (# #) #), Float#, Bool #)  (# (# Int, (# #) #),
> |  > Float#, Bool #) :: TYPE
> |  >                                            ('TupleRep
> |  >                                               '['TupleRep
> |  > '['LiftedRep, 'TupleRep '[]], 'FloatRep,
> |  >                                                 'LiftedRep])
> |  >
> |  > As you can see, each of these different nestings of unboxed tuples
> |  > yields different kinds, so they most certainly do *not* uphold the
> |  > property claimed in the paper.
> |  >
> |  > Is this a bug? Or is there some reason that GHC implemented it
> |  differently?
> |  >
> |  > Ryan S.
> |  > -----
> |  > [1]
> |  > https://www.microsoft.com/en-us/research/wp-
> |  content/uploads/2016/11/le
> |  > vity-1.pdf _______________________________________________
> |  > ghc-devs mailing list
> |  > ghc-devs at haskell.org
> |  > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> |  
> |  _______________________________________________
> |  ghc-devs mailing list
> |  ghc-devs at haskell.org
> |  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From adam at adamsteen.com.au  Sun Mar 26 11:24:07 2017
From: adam at adamsteen.com.au (Adam Steen)
Date: Sun, 26 Mar 2017 19:24:07 +0800
Subject: Building head on Openbsd
Message-ID: <CAAg4dOhyUCV-RF=xrk-HJykyQC8T519h6t+zTtfmNcTZTwHuoA@mail.gmail.com>

Hi

I attempt to build head today on OpenBSD current and failed, but i not sure
where to start to fix the problems. The full configure and build logs are
attached. Just a note: ghc-8.0 builds fine, ghc-8.2 fails with the same
error.

the first error is

"inplace/bin/ghc-stage1" -optc-std=gnu99 -optc-fno-stack-protector
-optc-Wall -optc-Wall -optc-Wextra -optc-Wstrict-prototypes
-optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Wi     nline
-optc-Waggregate-return -optc-Wpointer-arith -optc-Wmissing-noreturn
-optc-Wnested-externs -optc-Wredundant-decls -optc-Iincludes
-optc-Iincludes/dist -optc-Iincludes/dist-derivedcons     tants/header
-optc-Iincludes/dist-ghcconstants/header -optc-Irts -optc-Irts/dist/build
-optc-DCOMPILING_RTS -optc-fno-strict-aliasing -optc-fno-common
-optc-Irts/dist/build/./autogen -optc-     O2 -optc-fomit-frame-pointer
-optc-g -optc-DRtsWay=\"rts_v\" -optc-ffunction-sections
-optc-fdata-sections -static  -H32m -O -Wall   -Iincludes -Iincludes/dist
-Iincludes/dist-derivedconsta     nts/header
-Iincludes/dist-ghcconstants/header
-Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint      -i
-irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen
 -Irts/dist/build/./autogen           -O2    -Wnoncanonical-monad-instances
 -c rts/Timer.c -o rts/dist/build/Timer.o
 In file included from rts/posix/Signals.h:13,
                  from rts/RtsSignals.h:14,

                  from rts/Timer.c:26:0: error:

 /usr/include/signal.h:72:0: error:
      warning: redundant redeclaration of '__errno'
    |
72 | extern int *__errno(void);
    | ^

and the last error is

rts/linker/Elf.c:539:0: error:  warning: unused variable 'secno'
    |
539 |          Elf_Word secno = stab[j].st_shndx;
    | ^
`gcc' failed in phase `C Compiler'. (Exit code: 1)
gmake[1]: *** [rts/ghc.mk:248: rts/dist/build/linker/Elf.o] Error 1
gmake: *** [Makefile:127: all] Error 2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170326/a9a2363d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conf.log
Type: text/x-log
Size: 14605 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170326/a9a2363d/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.log
Type: text/x-log
Size: 3038290 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170326/a9a2363d/attachment-0003.bin>

From slyich at gmail.com  Sun Mar 26 13:04:08 2017
From: slyich at gmail.com (Sergei Trofimovich)
Date: Sun, 26 Mar 2017 14:04:08 +0100
Subject: Building head on Openbsd
In-Reply-To: <CAAg4dOhyUCV-RF=xrk-HJykyQC8T519h6t+zTtfmNcTZTwHuoA@mail.gmail.com>
References: <CAAg4dOhyUCV-RF=xrk-HJykyQC8T519h6t+zTtfmNcTZTwHuoA@mail.gmail.com>
Message-ID: <20170326140408.6a21ae99@sf>

On Sun, 26 Mar 2017 19:24:07 +0800
Adam Steen <adam at adamsteen.com.au> wrote:

> Hi
> 
> I attempt to build head today on OpenBSD current and failed, but i not sure
> where to start to fix the problems. The full configure and build logs are
> attached. Just a note: ghc-8.0 builds fine, ghc-8.2 fails with the same
> error.
> 
> the first error is
...
> rts/linker/Elf.c:539:0: error:  warning: unused variable 'secno'

There are just warnings. I think the real error is:

rts/linker/Elf.c:402:0: error:
     error: (Each undeclared identifier is reported only once
    |
402 |       case EM_PPC64: IF_DEBUG(linker,debugBelch( "powerpc64" ));
    | ^

I guess openbsd does not have definition of EM_PPC64 (yet?).
Try that to see how far it progresses:

diff --git a/rts/linker/Elf.c b/rts/linker/Elf.c
index 604c3dc..e8f6aab 100644
--- a/rts/linker/Elf.c
+++ b/rts/linker/Elf.c
@@ -400,8 +400,10 @@ ocVerifyImage_ELF ( ObjectCode* oc )
 #endif
       case EM_PPC:   IF_DEBUG(linker,debugBelch( "powerpc32" )); break;
+#ifdef EM_PPC64
       case EM_PPC64: IF_DEBUG(linker,debugBelch( "powerpc64" ));
           errorBelch("%s: RTS linker not implemented on PowerPC 64-bit",
                      oc->fileName);
           return 0;
+#endif
 #ifdef EM_X86_64
       case EM_X86_64: IF_DEBUG(linker,debugBelch( "x86_64" )); break;

-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: Цифровая подпись OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170326/e3f891fa/attachment.sig>

From karel.gardas at centrum.cz  Sun Mar 26 13:08:50 2017
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Sun, 26 Mar 2017 15:08:50 +0200
Subject: Building head on Openbsd
In-Reply-To: <20170326140408.6a21ae99@sf>
References: <CAAg4dOhyUCV-RF=xrk-HJykyQC8T519h6t+zTtfmNcTZTwHuoA@mail.gmail.com>
 <20170326140408.6a21ae99@sf>
Message-ID: <58D7BD62.9070303@centrum.cz>

On 03/26/17 03:04 PM, Sergei Trofimovich wrote:
> I guess openbsd does not have definition of EM_PPC64 (yet?).

IIRC it does not. I even remembering to fix this in the past but then 
probably forgotten to submit patch...

Anyway, attempting to duplicate on outdated OpenBSD current from Dec 
2016, but still post 6.0 code so this should be ok...

Karel


From slyich at gmail.com  Sun Mar 26 14:54:59 2017
From: slyich at gmail.com (Sergei Trofimovich)
Date: Sun, 26 Mar 2017 15:54:59 +0100
Subject: Building head on Openbsd
In-Reply-To: <58D7BD62.9070303@centrum.cz>
References: <CAAg4dOhyUCV-RF=xrk-HJykyQC8T519h6t+zTtfmNcTZTwHuoA@mail.gmail.com>
 <20170326140408.6a21ae99@sf> <58D7BD62.9070303@centrum.cz>
Message-ID: <20170326155459.16d12e77@sf>

On Sun, 26 Mar 2017 15:08:50 +0200
Karel Gardas <karel.gardas at centrum.cz> wrote:

> On 03/26/17 03:04 PM, Sergei Trofimovich wrote:
> > I guess openbsd does not have definition of EM_PPC64 (yet?).  
> 
> IIRC it does not. I even remembering to fix this in the past but then 
> probably forgotten to submit patch...
> 
> Anyway, attempting to duplicate on outdated OpenBSD current from Dec 
> 2016, but still post 6.0 code so this should be ok...

I've tested the following patch 
    https://git.haskell.org/ghc.git/commitdiff/6c73504ac5f4e951062d5e868fa2b69b028b6e79
on amd64-unknown-openbsd6.0.

Hope it does not breaks things for you.

-- 

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: Цифровая подпись OpenPGP
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170326/76e18c77/attachment.sig>

From karel.gardas at centrum.cz  Sun Mar 26 15:22:24 2017
From: karel.gardas at centrum.cz (Karel Gardas)
Date: Sun, 26 Mar 2017 17:22:24 +0200
Subject: Building head on Openbsd
In-Reply-To: <20170326155459.16d12e77@sf>
References: <CAAg4dOhyUCV-RF=xrk-HJykyQC8T519h6t+zTtfmNcTZTwHuoA@mail.gmail.com>
 <20170326140408.6a21ae99@sf> <58D7BD62.9070303@centrum.cz>
 <20170326155459.16d12e77@sf>
Message-ID: <58D7DCB0.70400@centrum.cz>

On 03/26/17 04:54 PM, Sergei Trofimovich wrote:
> On Sun, 26 Mar 2017 15:08:50 +0200
> Karel Gardas <karel.gardas at centrum.cz> wrote:
>
>> On 03/26/17 03:04 PM, Sergei Trofimovich wrote:
>>> I guess openbsd does not have definition of EM_PPC64 (yet?).
>>
>> IIRC it does not. I even remembering to fix this in the past but then
>> probably forgotten to submit patch...
>>
>> Anyway, attempting to duplicate on outdated OpenBSD current from Dec
>> 2016, but still post 6.0 code so this should be ok...
>
> I've tested the following patch
>      https://git.haskell.org/ghc.git/commitdiff/6c73504ac5f4e951062d5e868fa2b69b028b6e79
> on amd64-unknown-openbsd6.0.
>
> Hope it does not breaks things for you.

Well, my patch looks exactly like yours. Anyway, thanks for such fast 
solution and commit.

Karel


From ben at smart-cactus.org  Mon Mar 27 03:23:05 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Sun, 26 Mar 2017 23:23:05 -0400
Subject: Building head on Openbsd
In-Reply-To: <58D7DCB0.70400@centrum.cz>
References: <CAAg4dOhyUCV-RF=xrk-HJykyQC8T519h6t+zTtfmNcTZTwHuoA@mail.gmail.com>
 <20170326140408.6a21ae99@sf> <58D7BD62.9070303@centrum.cz>
 <20170326155459.16d12e77@sf> <58D7DCB0.70400@centrum.cz>
Message-ID: <87bmsne73a.fsf@ben-laptop.smart-cactus.org>

Karel Gardas <karel.gardas at centrum.cz> writes:

> On 03/26/17 04:54 PM, Sergei Trofimovich wrote:
>> On Sun, 26 Mar 2017 15:08:50 +0200
>> Karel Gardas <karel.gardas at centrum.cz> wrote:
>>
>>> On 03/26/17 03:04 PM, Sergei Trofimovich wrote:
>>>> I guess openbsd does not have definition of EM_PPC64 (yet?).
>>>
>>> IIRC it does not. I even remembering to fix this in the past but then
>>> probably forgotten to submit patch...
>>>
>>> Anyway, attempting to duplicate on outdated OpenBSD current from Dec
>>> 2016, but still post 6.0 code so this should be ok...
>>
>> I've tested the following patch
>>      https://git.haskell.org/ghc.git/commitdiff/6c73504ac5f4e951062d5e868fa2b69b028b6e79
>> on amd64-unknown-openbsd6.0.
>>
>> Hope it does not breaks things for you.
>
> Well, my patch looks exactly like yours. Anyway, thanks for such fast 
> solution and commit.
>
I have cherry-picked the fix into 8.2 as
d4694b85be23c8a014225271060765c062502ed2.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170326/a4130230/attachment.sig>

From simonpj at microsoft.com  Mon Mar 27 10:21:44 2017
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 27 Mar 2017 10:21:44 +0000
Subject: SPECIALISE INLINE pragma
In-Reply-To: <CAHFo2uq+=bAXJfBahcE2ctJW+g_BskGJ26_gdjjThbbuD0yYQg@mail.gmail.com>
References: <CALuQ0m8ViQdzNRGmz0zpzNwsqVkvXdynmtY4TvGuHQ2KCHrJJQ@mail.gmail.com>
 <CAHFo2up+LAcrNqyoqr5eh-H6rz99FdZJsa5mxuBG4mSsNYRr+g@mail.gmail.com>
 <DM2PR21MB002881A5D850DE034A9274E7AD3C0@DM2PR21MB0028.namprd21.prod.outlook.com>
 <CAHFo2uq+=bAXJfBahcE2ctJW+g_BskGJ26_gdjjThbbuD0yYQg@mail.gmail.com>
Message-ID: <DM2PR21MB0028B19BADA4040E6102866EAD330@DM2PR21MB0028.namprd21.prod.outlook.com>

|  A warning would be very welcome. Given that the debugging compiler
|  emits one, perhaps it's not too difficult to add.

That's a good idea; but it's a bit tricky: see Trac #9418.

It _must_ be possible to do better here.

Simon

|  -----Original Message-----
|  From: Mikolaj Konarski [mailto:mikolaj at well-typed.com]
|  Sent: 23 March 2017 21:15
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: Matthew Pickering <matthewtpickering at gmail.com>; GHC developers
|  <ghc-devs at haskell.org>
|  Subject: Re: SPECIALISE INLINE pragma
|  
|  > GHC tries hard NOT to choose an INLINE function as a loop breaker.
|  > But if you write
|  >
|  > f x = if ... then 0 else (f x')
|  > {-# INLINE f #-}
|  >
|  > then the only possible loop breaker is 'f', so GHC has to choose it.
|  
|  Indeed.
|  
|  > What else would you suggest?
|  
|  A warning would be very welcome. Given that the debugging compiler
|  emits one, perhaps it's not too difficult to add.
|  
|  Apart of that, if the heuristics is based not on INLINE pragmas, but
|  on available unfoldings, as Matthew suggests in his wiki article, I'd
|  propose to fix that, see the case below.
|  
|  > What puzzling behaviour do you have in mind?
|  
|  I can't reconstruct it now, but I was profiling as set of mutually
|  recursive functions, with -fexpose-all-unfoldings (so GHC could not
|  decide based on available unfoldings) and INLINE on only some of them
|  (I don't remember if the others had NOINLINE or nothing).
|  I had an impression some of the INLINEs where ignored and that the
|  loop breaker was not at the place I was forcing, but the impression
|  was based only on comparison of runtimes of different variants, not on
|  inspecting core. A warning would really help next time to let me catch
|  a concrete example to post.

From ggreif at gmail.com  Mon Mar 27 11:00:16 2017
From: ggreif at gmail.com (Gabor Greif)
Date: Mon, 27 Mar 2017 13:00:16 +0200
Subject: [commit: ghc] master: rts linker: Introduce MachOTypes (8ed29b5)
In-Reply-To: <20170327030100.C14813A584@ghc.haskell.org>
References: <20170327030100.C14813A584@ghc.haskell.org>
Message-ID: <CAK-hX0nn1Q8Ko9H-Yd--UzBNB21-LYTrV-Pu7WSrvwAKgOWLEg@mail.gmail.com>

This commit 8ed29b50376856018dfbbcbd6d728c69af0c9f29 introduced a
compilation failure with gcc4.4 (my gcc). The typedef-name
`SectionFormatInfo` is redefined.

Here is the reason:
http://stackoverflow.com/questions/6526322/why-redefinition-of-typedef-error-with-gcc-4-3-but-not-gcc-4-6

I have a fix in testing, will commit shortly.

Cheers,

    Gabor

On 3/27/17, git at git.haskell.org <git at git.haskell.org> wrote:
> Repository : ssh://git at git.haskell.org/ghc
>
> On branch  : master
> Link       :
> http://ghc.haskell.org/trac/ghc/changeset/8ed29b50376856018dfbbcbd6d728c69af0c9f29/ghc
>
>>---------------------------------------------------------------
>
> commit 8ed29b50376856018dfbbcbd6d728c69af0c9f29
> Author: Moritz Angermann <moritz.angermann at gmail.com>
> Date:   Tue Mar 21 10:59:49 2017 -0400
>
>     rts linker: Introduce MachOTypes
>
>     This diff introduces MachOTypes, to reduce the need to typing `struct`
>     all the time.  It also coaleces the 64 and non 64 structs. It also adds
>     additional fiedls to the object code structure for macho, which makes
>     working with macho object code much simpler and requires less passing
>     around of variabls or address recomputation for the header, symbol
>     table, etc...
>
>     Furthermore this diff introduces a type for a linked list of stubs.
>
>     I had to move the #ifdef from the bottom of the file up, to be able to
>     extend the object code structure conditional on the use of the macho
> file format.
>
>     This is just one of the pieces for the rts linker
>     support for ios (aarch64-macho)
>
>     ---
>
>     The following diagram and legend tries to explain the dependencies a
>     bit:
>     ```
>       .- D3240
>       v
>     D3255 <- D3252 <- D3251 <- This
>       ^
>       '- D3238
>     ```
>
>     - In D3238 we started allowing preloading object code with mmap
>       in iOS, where we can't have r+w+x.
>     - In D3239 we introduced a richer extension of the object code
>       data type to make working with mach-o files easier.
>     - In D3240 we set the stage to allow loading archives (.a) on iOS
>     - In D3251 we added init and deinit functions to populate and
>       depopulate the enriched object code data structure for mach-o
>       files.
>     - In D3252 we refactored most of the MachO.c file to use the
>       new types and data structure.
>     - in D3255 we finally introduce the aarch64-mach-o linker.
>
>     Reviewers: austin, erikd, simonmar, rwbarton, bgamari
>
>     Subscribers: rwbarton, thomie, ryantrinkle
>
>     Differential Revision: https://phabricator.haskell.org/D3239
>
>
>>---------------------------------------------------------------
>
> 8ed29b50376856018dfbbcbd6d728c69af0c9f29
>  rts/Linker.c            |   6 +++
>  rts/LinkerInternals.h   |  28 +++++++++-
>  rts/linker/MachOTypes.h | 133
> ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 165 insertions(+), 2 deletions(-)
>
> Diff suppressed because of size. To see it, use:
>
>     git diff-tree --root --patch-with-stat --no-color --find-copies-harder
> --ignore-space-at-eol --cc 8ed29b50376856018dfbbcbd6d728c69af0c9f29
> _______________________________________________
> ghc-commits mailing list
> ghc-commits at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits
>

From ggreif at gmail.com  Mon Mar 27 12:50:30 2017
From: ggreif at gmail.com (Gabor Greif)
Date: Mon, 27 Mar 2017 14:50:30 +0200
Subject: [commit: ghc] master: rts linker: Introduce MachOTypes (8ed29b5)
In-Reply-To: <CAK-hX0nn1Q8Ko9H-Yd--UzBNB21-LYTrV-Pu7WSrvwAKgOWLEg@mail.gmail.com>
References: <20170327030100.C14813A584@ghc.haskell.org>
 <CAK-hX0nn1Q8Ko9H-Yd--UzBNB21-LYTrV-Pu7WSrvwAKgOWLEg@mail.gmail.com>
Message-ID: <CAK-hX0nq23EGUnrOgFJFDTCv1GHAR6SNFRBHRH11yYwPmsh7mg@mail.gmail.com>

Hi Moritz,

I have just committed a6675a93efe7cae2f206508047a39e73ce4e92a5

There are two more spots to clean up, which I have left to you,
since I have no MachO machine to test on:

```
git grep "_.*FormatInfo" | grep -v LinkerInternals.h
linker/MachOTypes.h:typedef struct _ObjectCodeFormatInfo {
linker/MachOTypes.h:typedef struct _SectionFormatInfo {
```

I suggest that you apply the same transformation unless the LinkerInternals.h's
definition does not apply for this case.

Cheers,

    Gabor


On 3/27/17, Gabor Greif <ggreif at gmail.com> wrote:
> This commit 8ed29b50376856018dfbbcbd6d728c69af0c9f29 introduced a
> compilation failure with gcc4.4 (my gcc). The typedef-name
> `SectionFormatInfo` is redefined.
>
> Here is the reason:
> http://stackoverflow.com/questions/6526322/why-redefinition-of-typedef-error-with-gcc-4-3-but-not-gcc-4-6
>
> I have a fix in testing, will commit shortly.
>
> Cheers,
>
>     Gabor
>
> On 3/27/17, git at git.haskell.org <git at git.haskell.org> wrote:
>> Repository : ssh://git at git.haskell.org/ghc
>>
>> On branch  : master
>> Link       :
>> http://ghc.haskell.org/trac/ghc/changeset/8ed29b50376856018dfbbcbd6d728c69af0c9f29/ghc
>>
>>>---------------------------------------------------------------
>>
>> commit 8ed29b50376856018dfbbcbd6d728c69af0c9f29
>> Author: Moritz Angermann <moritz.angermann at gmail.com>
>> Date:   Tue Mar 21 10:59:49 2017 -0400
>>
>>     rts linker: Introduce MachOTypes
>>
>>     This diff introduces MachOTypes, to reduce the need to typing
>> `struct`
>>     all the time.  It also coaleces the 64 and non 64 structs. It also
>> adds
>>     additional fiedls to the object code structure for macho, which makes
>>     working with macho object code much simpler and requires less passing
>>     around of variabls or address recomputation for the header, symbol
>>     table, etc...
>>
>>     Furthermore this diff introduces a type for a linked list of stubs.
>>
>>     I had to move the #ifdef from the bottom of the file up, to be able
>> to
>>     extend the object code structure conditional on the use of the macho
>> file format.
>>
>>     This is just one of the pieces for the rts linker
>>     support for ios (aarch64-macho)
>>
>>     ---
>>
>>     The following diagram and legend tries to explain the dependencies a
>>     bit:
>>     ```
>>       .- D3240
>>       v
>>     D3255 <- D3252 <- D3251 <- This
>>       ^
>>       '- D3238
>>     ```
>>
>>     - In D3238 we started allowing preloading object code with mmap
>>       in iOS, where we can't have r+w+x.
>>     - In D3239 we introduced a richer extension of the object code
>>       data type to make working with mach-o files easier.
>>     - In D3240 we set the stage to allow loading archives (.a) on iOS
>>     - In D3251 we added init and deinit functions to populate and
>>       depopulate the enriched object code data structure for mach-o
>>       files.
>>     - In D3252 we refactored most of the MachO.c file to use the
>>       new types and data structure.
>>     - in D3255 we finally introduce the aarch64-mach-o linker.
>>
>>     Reviewers: austin, erikd, simonmar, rwbarton, bgamari
>>
>>     Subscribers: rwbarton, thomie, ryantrinkle
>>
>>     Differential Revision: https://phabricator.haskell.org/D3239
>>
>>
>>>---------------------------------------------------------------
>>
>> 8ed29b50376856018dfbbcbd6d728c69af0c9f29
>>  rts/Linker.c            |   6 +++
>>  rts/LinkerInternals.h   |  28 +++++++++-
>>  rts/linker/MachOTypes.h | 133
>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>  3 files changed, 165 insertions(+), 2 deletions(-)
>>
>> Diff suppressed because of size. To see it, use:
>>
>>     git diff-tree --root --patch-with-stat --no-color
>> --find-copies-harder
>> --ignore-space-at-eol --cc 8ed29b50376856018dfbbcbd6d728c69af0c9f29
>> _______________________________________________
>> ghc-commits mailing list
>> ghc-commits at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits
>>
>

From moritz.angermann at gmail.com  Mon Mar 27 14:23:01 2017
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 27 Mar 2017 22:23:01 +0800
Subject: [commit: ghc] master: rts linker: Introduce MachOTypes (8ed29b5)
In-Reply-To: <CAK-hX0nq23EGUnrOgFJFDTCv1GHAR6SNFRBHRH11yYwPmsh7mg@mail.gmail.com>
References: <20170327030100.C14813A584@ghc.haskell.org>
 <CAK-hX0nn1Q8Ko9H-Yd--UzBNB21-LYTrV-Pu7WSrvwAKgOWLEg@mail.gmail.com>
 <CAK-hX0nq23EGUnrOgFJFDTCv1GHAR6SNFRBHRH11yYwPmsh7mg@mail.gmail.com>
Message-ID: <60914E4C-6B8B-475A-A1EE-7F24CA3F9484@gmail.com>

Hi Gabor,

thanks! And sorry for causing trouble.  I’ll look into the MachO
case.

Cheers,
 Moritz
> On Mar 27, 2017, at 8:50 PM, Gabor Greif <ggreif at gmail.com> wrote:
> 
> Hi Moritz,
> 
> I have just committed a6675a93efe7cae2f206508047a39e73ce4e92a5
> 
> There are two more spots to clean up, which I have left to you,
> since I have no MachO machine to test on:
> 
> ```
> git grep "_.*FormatInfo" | grep -v LinkerInternals.h
> linker/MachOTypes.h:typedef struct _ObjectCodeFormatInfo {
> linker/MachOTypes.h:typedef struct _SectionFormatInfo {
> ```
> 
> I suggest that you apply the same transformation unless the LinkerInternals.h's
> definition does not apply for this case.
> 
> Cheers,
> 
>    Gabor
> 
> 
> On 3/27/17, Gabor Greif <ggreif at gmail.com> wrote:
>> This commit 8ed29b50376856018dfbbcbd6d728c69af0c9f29 introduced a
>> compilation failure with gcc4.4 (my gcc). The typedef-name
>> `SectionFormatInfo` is redefined.
>> 
>> Here is the reason:
>> http://stackoverflow.com/questions/6526322/why-redefinition-of-typedef-error-with-gcc-4-3-but-not-gcc-4-6
>> 
>> I have a fix in testing, will commit shortly.
>> 
>> Cheers,
>> 
>>    Gabor
>> 
>> On 3/27/17, git at git.haskell.org <git at git.haskell.org> wrote:
>>> Repository : ssh://git at git.haskell.org/ghc
>>> 
>>> On branch  : master
>>> Link       :
>>> http://ghc.haskell.org/trac/ghc/changeset/8ed29b50376856018dfbbcbd6d728c69af0c9f29/ghc
>>> 
>>>> ---------------------------------------------------------------
>>> 
>>> commit 8ed29b50376856018dfbbcbd6d728c69af0c9f29
>>> Author: Moritz Angermann <moritz.angermann at gmail.com>
>>> Date:   Tue Mar 21 10:59:49 2017 -0400
>>> 
>>>    rts linker: Introduce MachOTypes
>>> 
>>>    This diff introduces MachOTypes, to reduce the need to typing
>>> `struct`
>>>    all the time.  It also coaleces the 64 and non 64 structs. It also
>>> adds
>>>    additional fiedls to the object code structure for macho, which makes
>>>    working with macho object code much simpler and requires less passing
>>>    around of variabls or address recomputation for the header, symbol
>>>    table, etc...
>>> 
>>>    Furthermore this diff introduces a type for a linked list of stubs.
>>> 
>>>    I had to move the #ifdef from the bottom of the file up, to be able
>>> to
>>>    extend the object code structure conditional on the use of the macho
>>> file format.
>>> 
>>>    This is just one of the pieces for the rts linker
>>>    support for ios (aarch64-macho)
>>> 
>>>    ---
>>> 
>>>    The following diagram and legend tries to explain the dependencies a
>>>    bit:
>>>    ```
>>>      .- D3240
>>>      v
>>>    D3255 <- D3252 <- D3251 <- This
>>>      ^
>>>      '- D3238
>>>    ```
>>> 
>>>    - In D3238 we started allowing preloading object code with mmap
>>>      in iOS, where we can't have r+w+x.
>>>    - In D3239 we introduced a richer extension of the object code
>>>      data type to make working with mach-o files easier.
>>>    - In D3240 we set the stage to allow loading archives (.a) on iOS
>>>    - In D3251 we added init and deinit functions to populate and
>>>      depopulate the enriched object code data structure for mach-o
>>>      files.
>>>    - In D3252 we refactored most of the MachO.c file to use the
>>>      new types and data structure.
>>>    - in D3255 we finally introduce the aarch64-mach-o linker.
>>> 
>>>    Reviewers: austin, erikd, simonmar, rwbarton, bgamari
>>> 
>>>    Subscribers: rwbarton, thomie, ryantrinkle
>>> 
>>>    Differential Revision: https://phabricator.haskell.org/D3239
>>> 
>>> 
>>>> ---------------------------------------------------------------
>>> 
>>> 8ed29b50376856018dfbbcbd6d728c69af0c9f29
>>> rts/Linker.c            |   6 +++
>>> rts/LinkerInternals.h   |  28 +++++++++-
>>> rts/linker/MachOTypes.h | 133
>>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 165 insertions(+), 2 deletions(-)
>>> 
>>> Diff suppressed because of size. To see it, use:
>>> 
>>>    git diff-tree --root --patch-with-stat --no-color
>>> --find-copies-harder
>>> --ignore-space-at-eol --cc 8ed29b50376856018dfbbcbd6d728c69af0c9f29
>>> _______________________________________________
>>> ghc-commits mailing list
>>> ghc-commits at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits
>>> 
>> 


From ben at smart-cactus.org  Mon Mar 27 15:01:28 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 27 Mar 2017 11:01:28 -0400
Subject: [commit: ghc] master: rts linker: Introduce MachOTypes (8ed29b5)
In-Reply-To: <60914E4C-6B8B-475A-A1EE-7F24CA3F9484@gmail.com>
References: <20170327030100.C14813A584@ghc.haskell.org>
 <CAK-hX0nn1Q8Ko9H-Yd--UzBNB21-LYTrV-Pu7WSrvwAKgOWLEg@mail.gmail.com>
 <CAK-hX0nq23EGUnrOgFJFDTCv1GHAR6SNFRBHRH11yYwPmsh7mg@mail.gmail.com>
 <60914E4C-6B8B-475A-A1EE-7F24CA3F9484@gmail.com>
Message-ID: <874lyeepbr.fsf@ben-laptop.smart-cactus.org>

Moritz Angermann <moritz.angermann at gmail.com> writes:

> Hi Gabor,
>
> thanks! And sorry for causing trouble.  I’ll look into the MachO
> case.
>
Thanks for handling this Gabor and Moritz!

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170327/2811d02d/attachment.sig>

From ben at well-typed.com  Mon Mar 27 15:41:56 2017
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 27 Mar 2017 11:41:56 -0400
Subject: GHC 8.2.1 status
Message-ID: <871stiengb.fsf@ben-laptop.smart-cactus.org>

Hello everyone,

Here is your periodic release update. After a number of false-starts,
the tree is finally approaching a releasable state. Last week I cut
the ghc-8.2 branch and things have been stabilizing ever since. At this
point we are waiting on only a couple more fixes before the rc1 source
release can be cut,

 * #13474: To be addressed by Richard soon
 * #13410: To be addressed by Simon PJ shortly
 * #13333: To be addressed by Ben shortly
 * #13433: Simon Marow has a fix

There are also a few issues that we have deemed not to block -rc1, but
which must be addressed prior to the final release,

 * #13220: David will verify that 
 * #13233: Ben will do a bit more digging, Simon PJ will think about it

With luck we will be able to finish the -rc1 blockers in the next couple
of days, allowing us to cut a source release by Tuesday or Wednesday.

Cheers,

 - Your friendly release manager
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170327/2779717b/attachment.sig>

From george.colpitts at gmail.com  Mon Mar 27 15:49:06 2017
From: george.colpitts at gmail.com (George Colpitts)
Date: Mon, 27 Mar 2017 15:49:06 +0000
Subject: GHC 8.2.1 status
In-Reply-To: <871stiengb.fsf@ben-laptop.smart-cactus.org>
References: <871stiengb.fsf@ben-laptop.smart-cactus.org>
Message-ID: <CAB-d4A7t0Tnm4S6fqwKHaZb1ST3+-nvUYtx=KOjG2TD7fROtPw@mail.gmail.com>

Thanks Ben. When you have a chance it would be good to update the status
page <https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.2.1> wrt what we
will be getting, specifically will Backpack be in 8.2.1

Cheers
George

On Mon, Mar 27, 2017 at 12:42 PM Ben Gamari <ben at well-typed.com> wrote:

> Hello everyone,
>
> Here is your periodic release update. After a number of false-starts,
> the tree is finally approaching a releasable state. Last week I cut
> the ghc-8.2 branch and things have been stabilizing ever since. At this
> point we are waiting on only a couple more fixes before the rc1 source
> release can be cut,
>
>  * #13474: To be addressed by Richard soon
>  * #13410: To be addressed by Simon PJ shortly
>  * #13333: To be addressed by Ben shortly
>  * #13433: Simon Marow has a fix
>
> There are also a few issues that we have deemed not to block -rc1, but
> which must be addressed prior to the final release,
>
>  * #13220: David will verify that
>  * #13233: Ben will do a bit more digging, Simon PJ will think about it
>
> With luck we will be able to finish the -rc1 blockers in the next couple
> of days, allowing us to cut a source release by Tuesday or Wednesday.
>
> Cheers,
>
>  - Your friendly release manager
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170327/b4dc1987/attachment.html>

From moritz.angermann at gmail.com  Mon Mar 27 14:23:01 2017
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 27 Mar 2017 22:23:01 +0800
Subject: [commit: ghc] master: rts linker: Introduce MachOTypes (8ed29b5)
In-Reply-To: <CAK-hX0nq23EGUnrOgFJFDTCv1GHAR6SNFRBHRH11yYwPmsh7mg@mail.gmail.com>
References: <20170327030100.C14813A584@ghc.haskell.org>
 <CAK-hX0nn1Q8Ko9H-Yd--UzBNB21-LYTrV-Pu7WSrvwAKgOWLEg@mail.gmail.com>
 <CAK-hX0nq23EGUnrOgFJFDTCv1GHAR6SNFRBHRH11yYwPmsh7mg@mail.gmail.com>
Message-ID: <60914E4C-6B8B-475A-A1EE-7F24CA3F9484@gmail.com>

Hi Gabor,

thanks! And sorry for causing trouble.  I’ll look into the MachO
case.

Cheers,
 Moritz
> On Mar 27, 2017, at 8:50 PM, Gabor Greif <ggreif at gmail.com> wrote:
> 
> Hi Moritz,
> 
> I have just committed a6675a93efe7cae2f206508047a39e73ce4e92a5
> 
> There are two more spots to clean up, which I have left to you,
> since I have no MachO machine to test on:
> 
> ```
> git grep "_.*FormatInfo" | grep -v LinkerInternals.h
> linker/MachOTypes.h:typedef struct _ObjectCodeFormatInfo {
> linker/MachOTypes.h:typedef struct _SectionFormatInfo {
> ```
> 
> I suggest that you apply the same transformation unless the LinkerInternals.h's
> definition does not apply for this case.
> 
> Cheers,
> 
>    Gabor
> 
> 
> On 3/27/17, Gabor Greif <ggreif at gmail.com> wrote:
>> This commit 8ed29b50376856018dfbbcbd6d728c69af0c9f29 introduced a
>> compilation failure with gcc4.4 (my gcc). The typedef-name
>> `SectionFormatInfo` is redefined.
>> 
>> Here is the reason:
>> http://stackoverflow.com/questions/6526322/why-redefinition-of-typedef-error-with-gcc-4-3-but-not-gcc-4-6
>> 
>> I have a fix in testing, will commit shortly.
>> 
>> Cheers,
>> 
>>    Gabor
>> 
>> On 3/27/17, git at git.haskell.org <git at git.haskell.org> wrote:
>>> Repository : ssh://git at git.haskell.org/ghc
>>> 
>>> On branch  : master
>>> Link       :
>>> http://ghc.haskell.org/trac/ghc/changeset/8ed29b50376856018dfbbcbd6d728c69af0c9f29/ghc
>>> 
>>>> ---------------------------------------------------------------
>>> 
>>> commit 8ed29b50376856018dfbbcbd6d728c69af0c9f29
>>> Author: Moritz Angermann <moritz.angermann at gmail.com>
>>> Date:   Tue Mar 21 10:59:49 2017 -0400
>>> 
>>>    rts linker: Introduce MachOTypes
>>> 
>>>    This diff introduces MachOTypes, to reduce the need to typing
>>> `struct`
>>>    all the time.  It also coaleces the 64 and non 64 structs. It also
>>> adds
>>>    additional fiedls to the object code structure for macho, which makes
>>>    working with macho object code much simpler and requires less passing
>>>    around of variabls or address recomputation for the header, symbol
>>>    table, etc...
>>> 
>>>    Furthermore this diff introduces a type for a linked list of stubs.
>>> 
>>>    I had to move the #ifdef from the bottom of the file up, to be able
>>> to
>>>    extend the object code structure conditional on the use of the macho
>>> file format.
>>> 
>>>    This is just one of the pieces for the rts linker
>>>    support for ios (aarch64-macho)
>>> 
>>>    ---
>>> 
>>>    The following diagram and legend tries to explain the dependencies a
>>>    bit:
>>>    ```
>>>      .- D3240
>>>      v
>>>    D3255 <- D3252 <- D3251 <- This
>>>      ^
>>>      '- D3238
>>>    ```
>>> 
>>>    - In D3238 we started allowing preloading object code with mmap
>>>      in iOS, where we can't have r+w+x.
>>>    - In D3239 we introduced a richer extension of the object code
>>>      data type to make working with mach-o files easier.
>>>    - In D3240 we set the stage to allow loading archives (.a) on iOS
>>>    - In D3251 we added init and deinit functions to populate and
>>>      depopulate the enriched object code data structure for mach-o
>>>      files.
>>>    - In D3252 we refactored most of the MachO.c file to use the
>>>      new types and data structure.
>>>    - in D3255 we finally introduce the aarch64-mach-o linker.
>>> 
>>>    Reviewers: austin, erikd, simonmar, rwbarton, bgamari
>>> 
>>>    Subscribers: rwbarton, thomie, ryantrinkle
>>> 
>>>    Differential Revision: https://phabricator.haskell.org/D3239
>>> 
>>> 
>>>> ---------------------------------------------------------------
>>> 
>>> 8ed29b50376856018dfbbcbd6d728c69af0c9f29
>>> rts/Linker.c            |   6 +++
>>> rts/LinkerInternals.h   |  28 +++++++++-
>>> rts/linker/MachOTypes.h | 133
>>> ++++++++++++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 165 insertions(+), 2 deletions(-)
>>> 
>>> Diff suppressed because of size. To see it, use:
>>> 
>>>    git diff-tree --root --patch-with-stat --no-color
>>> --find-copies-harder
>>> --ignore-space-at-eol --cc 8ed29b50376856018dfbbcbd6d728c69af0c9f29
>>> _______________________________________________
>>> ghc-commits mailing list
>>> ghc-commits at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits
>>> 
>> 


From ben at well-typed.com  Mon Mar 27 16:00:19 2017
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 27 Mar 2017 12:00:19 -0400
Subject: GHC 8.2.1 status
In-Reply-To: <CAB-d4A7t0Tnm4S6fqwKHaZb1ST3+-nvUYtx=KOjG2TD7fROtPw@mail.gmail.com>
References: <871stiengb.fsf@ben-laptop.smart-cactus.org>
 <CAB-d4A7t0Tnm4S6fqwKHaZb1ST3+-nvUYtx=KOjG2TD7fROtPw@mail.gmail.com>
Message-ID: <87y3vqd818.fsf@ben-laptop.smart-cactus.org>

George Colpitts <george.colpitts at gmail.com> writes:

> Thanks Ben. When you have a chance it would be good to update the status
> page <https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.2.1> wrt what we
> will be getting, specifically will Backpack be in 8.2.1
>
Hi George,

I just reviewed the status page and cleaned a few things up. Otherwise it looks up to date.

Regarding Backpack, all of the major pieces are currently in the tree
and will be present in 8.2. It would be great if users could play these
bits in -rc1; there has been a steady stream of fixes from Edward in the
past weeks, so there is no doubt more work to do here and it would be
great to find issues before the final release if possible.

Edward: Do you think you could add some details to the Backpack entry on
the status page?

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170327/11f1c9c7/attachment.sig>

From ezyang at mit.edu  Tue Mar 28 20:10:57 2017
From: ezyang at mit.edu (Edward Z. Yang)
Date: Tue, 28 Mar 2017 16:10:57 -0400
Subject: GHC 8.2.1 status
In-Reply-To: <87y3vqd818.fsf@ben-laptop.smart-cactus.org>
References: <871stiengb.fsf@ben-laptop.smart-cactus.org>
 <CAB-d4A7t0Tnm4S6fqwKHaZb1ST3+-nvUYtx=KOjG2TD7fROtPw@mail.gmail.com>
 <87y3vqd818.fsf@ben-laptop.smart-cactus.org>
Message-ID: <1490731489-sup-904@sabre>

I updated the wiki page!

Excerpts from Ben Gamari's message of 2017-03-27 12:00:19 -0400:
> George Colpitts <george.colpitts at gmail.com> writes:
> 
> > Thanks Ben. When you have a chance it would be good to update the status
> > page <https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.2.1> wrt what we
> > will be getting, specifically will Backpack be in 8.2.1
> >
> Hi George,
> 
> I just reviewed the status page and cleaned a few things up. Otherwise it looks up to date.
> 
> Regarding Backpack, all of the major pieces are currently in the tree
> and will be present in 8.2. It would be great if users could play these
> bits in -rc1; there has been a steady stream of fixes from Edward in the
> past weeks, so there is no doubt more work to do here and it would be
> great to find issues before the final release if possible.
> 
> Edward: Do you think you could add some details to the Backpack entry on
> the status page?
> 
> Cheers,
> 
> - Ben

From ben at smart-cactus.org  Wed Mar 29 18:31:13 2017
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 29 Mar 2017 14:31:13 -0400
Subject: D3316 status
Message-ID: <871stg6iku.fsf@ben-laptop.smart-cactus.org>

Hi Richard,

It took me a bit longer than expected to get back to D3316 but I think I
am now done. It wasn't quite as trivial as I thought it might be, so I
thought I would summarize what was needed,

 1. tcSplitTyConApp_maybe and tcRepSplitTyConApp_maybe have been moved
    from TcType to Type to avoid import loops. I'm not terribly happy
    with this change, but I spent a fair amount of time looking for
    alternatives and it seems this is the least evil. Moreover, there is
    precedent for this in tcRepSplitAppTy_maybe. It would be nice to
    refactor TcType and friends to avoid this loop.

 2. TypeMap now respects the Constraint/Type distinction. I believe this
    is safe for the TypeMap uses in the typechecker itself. The only
    other use AFAICT is Specialise.CallKeySet, which I believe should
    also be fine under this change.

 3. TcInteract.matchTypeable now handles Constraint explicitly.

With all of this the T11715 test passes. I've uploaded my changes
relative to your patch as D3396 for your review.

However, I am a bit concerned with (2) as it runs contrary to your
original implementation, which changed coreViewOneStarKind to coreView.
What was the reasoning behind this?

The motivation for moving to tcView here is the dictionary cache, which
uses a TypeMap. Namely, if we solve for `Typeable Type`, and later look
for `Typeable Constraint` in the dictionary cache, we will incorrectly
find the `Typeable Type` dictionary.

Thoughts?

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170329/7d944c39/attachment.sig>

From rae at cs.brynmawr.edu  Thu Mar 30 01:16:42 2017
From: rae at cs.brynmawr.edu (Richard Eisenberg)
Date: Wed, 29 Mar 2017 21:16:42 -0400
Subject: D3316 status
In-Reply-To: <871stg6iku.fsf@ben-laptop.smart-cactus.org>
References: <871stg6iku.fsf@ben-laptop.smart-cactus.org>
Message-ID: <0ADC9B04-1695-4096-98DD-0D081A924D75@cs.brynmawr.edu>


> On Mar 29, 2017, at 2:31 PM, Ben Gamari <ben at smart-cactus.org> wrote:
> 
> Hi Richard,
> 
> It took me a bit longer than expected to get back to D3316 but I think I
> am now done. It wasn't quite as trivial as I thought it might be, so I
> thought I would summarize what was needed,
> 
> 1. tcSplitTyConApp_maybe and tcRepSplitTyConApp_maybe have been moved
>    from TcType to Type to avoid import loops. I'm not terribly happy
>    with this change, but I spent a fair amount of time looking for
>    alternatives and it seems this is the least evil. Moreover, there is
>    precedent for this in tcRepSplitAppTy_maybe. It would be nice to
>    refactor TcType and friends to avoid this loop.

Why do this functions get involved? Where do they get called? Unify? If so, good catch!

> 
> 2. TypeMap now respects the Constraint/Type distinction. I believe this
>    is safe for the TypeMap uses in the typechecker itself. The only
>    other use AFAICT is Specialise.CallKeySet, which I believe should
>    also be fine under this change.

Another good catch.

> 
> 3. TcInteract.matchTypeable now handles Constraint explicitly.

Hooray.

> 
> With all of this the T11715 test passes. I've uploaded my changes
> relative to your patch as D3396 for your review.

Thanks!! Will look tomorrow.

> 
> However, I am a bit concerned with (2) as it runs contrary to your
> original implementation, which changed coreViewOneStarKind to coreView.
> What was the reasoning behind this?

The reasoning was that we should consider (instance C Constraint) and (instance C Type) to be overlapping, so any kind of lookup should be over coreView types. This was before the T11480b bug was known and before the decision to let these instances not overlap. So I agree with your decision for (2).

> 
> The motivation for moving to tcView here is the dictionary cache, which
> uses a TypeMap. Namely, if we solve for `Typeable Type`, and later look
> for `Typeable Constraint` in the dictionary cache, we will incorrectly
> find the `Typeable Type` dictionary.
> 
> Thoughts?

That you've hit this one on the head. :)

Richard

> 
> Cheers,
> 
> - Ben