From qdunkan at gmail.com  Tue Nov  3 17:47:56 2015
From: qdunkan at gmail.com (Evan Laforge)
Date: Tue, 3 Nov 2015 09:47:56 -0800
Subject: record field names vs. -fwarn-unused-binds
Message-ID: <CACbaDy4uyjOzQrX=Lq58oorUy5X6JK_R2C+sqdg1Oiz+zhvHPg@mail.gmail.com>

[ ccing haskell-cafe since while it's a ghc flag, I'll bet most
compilers have an equivalent ]

I really like -fwarn-unused-binds because it frequently finds bugs
where I forgot to call something or use some value.  If I put an
export list on, it can find dead functions I forgot to delete.
However, there's one case where it frequently gives false positives,
and that's unused record field names.  The problem is that I sometimes
use record field names as documentation, but the record itself is
internal and small, so I'm comfortable using positional pattern
matching to open it (and in fact that can be safer, since then
warn-unused-binds will make sure I used all the fields).  But GHC sees
these as unused functions, so it warns about them.  I can work around
by putting underscores on field names I haven't used yet, but it's a
hassle to go edit them when I want to use them.  The warning can be
useful if it indicates an unused field, but since fields can also be
extracted via the positional syntax it's not reliable.  The other use
of the warning for dead code or functions you forgot to use doesn't
apply to record accessors because they're trivial and compiler
generated.

So, would it be reasonable to exclude record field accessors from
-fwarn-unused-binds?  Or is there another way to work around it?  I
guess GHC doesn't have a "suppress warning" pragma like Java does, but
even if we did it wouldn't be much better than changing the name, and
more likely to get stale.

From thomasmiedema at gmail.com  Tue Nov  3 18:42:51 2015
From: thomasmiedema at gmail.com (Thomas Miedema)
Date: Tue, 3 Nov 2015 19:42:51 +0100
Subject: record field names vs. -fwarn-unused-binds
In-Reply-To: <CACbaDy4uyjOzQrX=Lq58oorUy5X6JK_R2C+sqdg1Oiz+zhvHPg@mail.gmail.com>
References: <CACbaDy4uyjOzQrX=Lq58oorUy5X6JK_R2C+sqdg1Oiz+zhvHPg@mail.gmail.com>
Message-ID: <CAD3WKggRQacSff+Xg9_fSa_wN+CZPYvrWauCiViq9YrxrcVU=A@mail.gmail.com>

Through a patch
<https://git.haskell.org/ghc.git/commitdiff/aead01902e1c41e85b758dbafd15e60d08956374>
by Oleg Grenrus (phadej), GHC 8 will have the following new flags:
 -fwarn-unused-top-binds
 -fwarn-unused-local-binds
 -fwarn-unused-pattern-binds

So you'll be able to pick and choose.


On Tue, Nov 3, 2015 at 6:47 PM, Evan Laforge <qdunkan at gmail.com> wrote:

> [ ccing haskell-cafe since while it's a ghc flag, I'll bet most
> compilers have an equivalent ]
>
> I really like -fwarn-unused-binds because it frequently finds bugs
> where I forgot to call something or use some value.  If I put an
> export list on, it can find dead functions I forgot to delete.
> However, there's one case where it frequently gives false positives,
> and that's unused record field names.  The problem is that I sometimes
> use record field names as documentation, but the record itself is
> internal and small, so I'm comfortable using positional pattern
> matching to open it (and in fact that can be safer, since then
> warn-unused-binds will make sure I used all the fields).  But GHC sees
> these as unused functions, so it warns about them.  I can work around
> by putting underscores on field names I haven't used yet, but it's a
> hassle to go edit them when I want to use them.  The warning can be
> useful if it indicates an unused field, but since fields can also be
> extracted via the positional syntax it's not reliable.  The other use
> of the warning for dead code or functions you forgot to use doesn't
> apply to record accessors because they're trivial and compiler
> generated.
>
> So, would it be reasonable to exclude record field accessors from
> -fwarn-unused-binds?  Or is there another way to work around it?  I
> guess GHC doesn't have a "suppress warning" pragma like Java does, but
> even if we did it wouldn't be much better than changing the name, and
> more likely to get stale.
> _______________________________________________
> 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/glasgow-haskell-users/attachments/20151103/089ffa95/attachment.html>

From qdunkan at gmail.com  Wed Nov  4 00:37:48 2015
From: qdunkan at gmail.com (Evan Laforge)
Date: Tue, 3 Nov 2015 16:37:48 -0800
Subject: type error formatting
In-Reply-To: <CACbaDy79gnkqUquL5BRDcaZ+jJTTyvP0VdbsAdukscyzhAhmcw@mail.gmail.com>
References: <CACbaDy6u1UjX5SBMX4hKeWtvw69uJBS1-DWYCKkeoxvYH63Q3A@mail.gmail.com>
 <3097b47964924f189f925cfc55575cfb@DB4PR30MB030.064d.mgd.msft.net>
 <CACbaDy79gnkqUquL5BRDcaZ+jJTTyvP0VdbsAdukscyzhAhmcw@mail.gmail.com>
Message-ID: <CACbaDy6gVJ2KNcUJfZDE2agLqCa5UjQfecFdQsPQfOcdE1s71g@mail.gmail.com>

A diff is up at https://phabricator.haskell.org/D1427

On Sat, Oct 24, 2015 at 1:14 PM, Evan Laforge <qdunkan at gmail.com> wrote:
> Ok, ticket created.  I'll go see how much I can figure out on my own.
>
> https://ghc.haskell.org/trac/ghc/ticket/11014
>
> WRT the "bound at" bits in "relevant bindings", I have no strong opinion.
> What about omitting them if they are in the same file as the main error?  Or
> maybe they always are?  I'm not totally clear how it chooses which bindings
> are relevant.
>
> On Sat, Oct 24, 2015 at 12:50 PM, Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>>
>> I?m all for it.   Can advise.  (Make a ticket.)
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Simon
>>
>>
>>
>> From: Glasgow-haskell-users
>> [mailto:glasgow-haskell-users-bounces at haskell.org] On Behalf Of Evan Laforge
>> Sent: 24 October 2015 03:48
>> To: GHC users
>> Subject: type error formatting
>>
>>
>>
>> Here's a typical simple type error from GHC:
>>
>>
>>
>> Derive/Call/India/Pakhawaj.hs:142:62:
>>     Couldn't match type ?Text? with ?(a1, Syllable)?
>>     Expected type: [([(a1, Syllable)], [Sequence Bol])]
>>       Actual type: [([Syllable], [Sequence Bol])]
>>     Relevant bindings include
>>       syllables :: [(a1, Syllable)]
>>         (bound at Derive/Call/India/Pakhawaj.hs:141:16)
>>       best_match :: [(a1, Syllable)]
>>                     -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence
>> Bol)]))
>>         (bound at Derive/Call/India/Pakhawaj.hs:141:5)
>>     In the second argument of ?mapMaybe?, namely ?all_bols?
>>     In the second argument of ?($)?, namely
>>       ?mapMaybe (match_bols syllables) all_bols?
>>
>> I've been having more trouble than usual reading GHC's errors, and I
>> finally spent some time to think about it.  The problem is that this new
>> "relevant bindings include" section gets in between the expected and actual
>> types (I still don't like that wording but I've gotten used to it), which is
>> the most critical part, and the location context, which is second most
>> critical.  Notice the same effect in the previous sentence :)  After I see a
>> type error the next thing I want to see is the where it happened, so I have
>> to skip over the bindings, which can be long and complicated.  Then I
>> usually know what to do, and only look into the bindings if something more
>> complicated is going on, like wonky inference.  So how about reordering the
>> message:
>>
>> Derive/Call/India/Pakhawaj.hs:142:62:
>>     Couldn't match type ?Text? with ?(a1, Syllable)?
>>     Expected type: [([(a1, Syllable)], [Sequence Bol])]
>>       Actual type: [([Syllable], [Sequence Bol])]
>>     In the second argument of ?mapMaybe?, namely ?all_bols?
>>     In the second argument of ?($)?, namely
>>       ?mapMaybe (match_bols syllables) all_bols?
>>     Relevant bindings include
>>       syllables :: [(a1, Syllable)]
>>         (bound at Derive/Call/India/Pakhawaj.hs:141:16)
>>       best_match :: [(a1, Syllable)]
>>                     -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence
>> Bol)]))
>>         (bound at Derive/Call/India/Pakhawaj.hs:141:5)
>>
>> After this, why not go one step further and set off the various sections
>> visibly to make it easier to scan.  The context section can also be really
>> long if it gets an entire do block or record:
>>
>> Derive/Call/India/Pakhawaj.hs:142:62:
>>   * Couldn't match type ?Text? with ?(a1, Syllable)?
>>     Expected type: [([(a1, Syllable)], [Sequence Bol])]
>>       Actual type: [([Syllable], [Sequence Bol])]
>>   * In the second argument of ?mapMaybe?, namely ?all_bols?
>>     In the second argument of ?($)?, namely
>>       ?mapMaybe (match_bols syllables) all_bols?
>>   * Relevant bindings include
>>       syllables :: [(a1, Syllable)]
>>         (bound at Derive/Call/India/Pakhawaj.hs:141:16)
>>       best_match :: [(a1, Syllable)]
>>                     -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence
>> Bol)]))
>>         (bound at Derive/Call/India/Pakhawaj.hs:141:5)
>>
>>
>>
>> Or alternately, taking up a bit more vertical space:
>>
>>
>>
>> Derive/Call/India/Pakhawaj.hs:142:62:
>>     Couldn't match type ?Text? with ?(a1, Syllable)?
>>     Expected type: [([(a1, Syllable)], [Sequence Bol])]
>>       Actual type: [([Syllable], [Sequence Bol])]
>>
>>         -----------------------------
>>     In the second argument of ?mapMaybe?, namely ?all_bols?
>>     In the second argument of ?($)?, namely
>>       ?mapMaybe (match_bols syllables) all_bols?
>>
>>         -----------------------------
>>     Relevant bindings include
>>
>>       syllables :: [(a1, Syllable)]
>>         (bound at Derive/Call/India/Pakhawaj.hs:141:16)
>>       best_match :: [(a1, Syllable)]
>>                     -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence
>> Bol)]))
>>         (bound at Derive/Call/India/Pakhawaj.hs:141:5)
>>
>>
>>
>> Thoughts?  It seems simple enough that I could do myself, but of course
>> not without buy-in.
>
>

From lemming at henning-thielemann.de  Wed Nov  4 14:56:08 2015
From: lemming at henning-thielemann.de (Henning Thielemann)
Date: Wed, 4 Nov 2015 15:56:08 +0100 (CET)
Subject: [Haskell-cafe] record field names vs. -fwarn-unused-binds
In-Reply-To: <CACbaDy4uyjOzQrX=Lq58oorUy5X6JK_R2C+sqdg1Oiz+zhvHPg@mail.gmail.com>
References: <CACbaDy4uyjOzQrX=Lq58oorUy5X6JK_R2C+sqdg1Oiz+zhvHPg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1511041554080.10949@sputnik>


On Tue, 3 Nov 2015, Evan Laforge wrote:

> I can work around by putting underscores on field names I haven't used 
> yet, but it's a hassle to go edit them when I want to use them.

I do it this way and I do not consider it a work-around. The underscore is 
just the shortest way to say that a record field name is not used. It's 
shorter than any pragma could be.

From qdunkan at gmail.com  Wed Nov  4 17:20:17 2015
From: qdunkan at gmail.com (Evan Laforge)
Date: Wed, 4 Nov 2015 09:20:17 -0800
Subject: record field names vs. -fwarn-unused-binds
In-Reply-To: <CAD3WKggRQacSff+Xg9_fSa_wN+CZPYvrWauCiViq9YrxrcVU=A@mail.gmail.com>
References: <CACbaDy4uyjOzQrX=Lq58oorUy5X6JK_R2C+sqdg1Oiz+zhvHPg@mail.gmail.com>
 <CAD3WKggRQacSff+Xg9_fSa_wN+CZPYvrWauCiViq9YrxrcVU=A@mail.gmail.com>
Message-ID: <CACbaDy4rakc1F9ie6xT8kxP-+SkbORE1+6TuGtHz8=vkW_RvVQ@mail.gmail.com>

On Tue, Nov 3, 2015 at 10:42 AM, Thomas Miedema <thomasmiedema at gmail.com> wrote:
> Through a patch by Oleg Grenrus (phadej), GHC 8 will have the following new
> flags:
>  -fwarn-unused-top-binds
>  -fwarn-unused-local-binds
>  -fwarn-unused-pattern-binds
>
> So you'll be able to pick and choose.

I suppose a record accessor would be considered a top bind?  I still
kind of like getting warnings about those, just not the ones from
records...

On Wed, Nov 4, 2015 at 6:56 AM, Henning Thielemann
<lemming at henning-thielemann.de> wrote:
> I do it this way and I do not consider it a work-around. The underscore is
> just the shortest way to say that a record field name is not used. It's
> shorter than any pragma could be.

I agree, that's what I meant by "not much better than changing the name".

I guess it would have to be yet another flag like
-fwarn-unused-record-accessors... not sure if it would be worth it
though, considering it's a relatively minor issue.

From clintonmead at gmail.com  Mon Nov 23 03:15:05 2015
From: clintonmead at gmail.com (Clinton Mead)
Date: Mon, 23 Nov 2015 14:15:05 +1100
Subject: Running GHC LLVM output through LLVM bitcode linker first
Message-ID: <CAFDVgwGmu=evzTSuT4PmRq=dnZPM9eEwo6ajvJ9e1AsZ6TQL3A@mail.gmail.com>

Is there a way to run the LLVM code (both generated by Haskell and provided
by the user) though the LLVM bitcode linker to perform intermodule
optimizations (like inlining)

http://llvm.org/docs/CommandGuide/llvm-link.html

Here's some example code:

-- Main.hs --

{-# LANGUAGE MagicHash #-}
{-# LANGUAGE UnboxedTuples #-}
{-# LANGUAGE GHCForeignImportPrim #-}
{-# LANGUAGE ForeignFunctionInterface #-}
{-# LANGUAGE UnliftedFFITypes #-}
{-# LANGUAGE BangPatterns #-}

import GHC.Exts(Word(W#))
import GHC.Prim(Word#)

foreign import ccall llvmid :: Word# -> Word#

main = do
  line1 <- getLine
  let !(W# x1) = read line1
  let !r1 = llvminc x1
  print (W# r1)


-- funcs.ll --

define fastcc i64 @llvminc(i64 inreg %x) {
  %r = add i64 %x, 1
  ret i64 %r
}

When I compile like the following:

ghc -O2 -fllvm -keep-s-files Main.hs funcs.ll

I get an executable that performs correctly, but when I look at the
assembly output in Main.s I get the following:

callq suspendThread
movq %rax, %rbp
movq %rbx, %rdi
callq llvminc
movq %rax, %rbx
movq %rbp, %rdi
callq resumeThread

This leads me to believe that this is being done like a c call through
registers, but not inlined, though I'm not sure about this. I also suspect
sending the "Main.ll" and "funcs.ll" files through the LLVM bitcode linker
and then sending the resulting one bitcode to the LLVM compiler would
perform these intramodule optimisations.

Is there anyway to get GHC to use the LLVM bitcode linker to link all the
LLVM files (both user provided and resulting from GHC compilation) though
the LLVM bitcode linker first before the system linker?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151123/f6f1570f/attachment.html>

From ben at smart-cactus.org  Mon Nov 23 10:07:00 2015
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 23 Nov 2015 11:07:00 +0100
Subject: Running GHC LLVM output through LLVM bitcode linker first
In-Reply-To: <CAFDVgwGmu=evzTSuT4PmRq=dnZPM9eEwo6ajvJ9e1AsZ6TQL3A@mail.gmail.com>
References: <CAFDVgwGmu=evzTSuT4PmRq=dnZPM9eEwo6ajvJ9e1AsZ6TQL3A@mail.gmail.com>
Message-ID: <87wpt9uj0b.fsf@smart-cactus.org>

Clinton Mead <clintonmead at gmail.com> writes:

> Is there a way to run the LLVM code (both generated by Haskell and provided
> by the user) though the LLVM bitcode linker to perform intermodule
> optimizations (like inlining)
>
> http://llvm.org/docs/CommandGuide/llvm-link.html
>
> Here's some example code:
>
> -- Main.hs --
>
> {-# LANGUAGE MagicHash #-}
> {-# LANGUAGE UnboxedTuples #-}
> {-# LANGUAGE GHCForeignImportPrim #-}
> {-# LANGUAGE ForeignFunctionInterface #-}
> {-# LANGUAGE UnliftedFFITypes #-}
> {-# LANGUAGE BangPatterns #-}
>
> import GHC.Exts(Word(W#))
> import GHC.Prim(Word#)
>
> foreign import ccall llvmid :: Word# -> Word#
>
Are you sure this code compiled? The above should read `llvminc`.

Moreover, if you really want this call to be efficient you should mark
it as unsafe [1]. This will eliminate the `suspendThread`/`resumeThread`
calls, which add significant cost. After doing this is appears that the
call is only one extra `movq`,

	  movq	7(%rbx), %rdi
	  callq	llvminc

>
> When I compile like the following:
>
> ghc -O2 -fllvm -keep-s-files Main.hs funcs.ll
>
> I get an executable that performs correctly, but when I look at the
> assembly output in Main.s I get the following:
>
> callq suspendThread
> movq %rax, %rbp
> movq %rbx, %rdi
> callq llvminc
> movq %rax, %rbx
> movq %rbp, %rdi
> callq resumeThread
>
> This leads me to believe that this is being done like a c call through
> registers, but not inlined, though I'm not sure about this. I also suspect
> sending the "Main.ll" and "funcs.ll" files through the LLVM bitcode linker
> and then sending the resulting one bitcode to the LLVM compiler would
> perform these intramodule optimisations.
>
> Is there anyway to get GHC to use the LLVM bitcode linker to link all the
> LLVM files (both user provided and resulting from GHC compilation) though
> the LLVM bitcode linker first before the system linker?

In general I'm not sure that this would be safe. In particular, GHC's
calling convention is much different than that expected by LLVM's
link-time optimizer and while `llvminc` would be safe to inline here (as
it's a ccall), I'm not sure that this is the case in general.

What are you trying to do that requires such optimal code generation? If
you want to put a call like this in an inner loop you'd likely be better
off either writing the entire loop in LLVM or adding a new primop to
GHC.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/glasgow-haskell-users/attachments/20151123/c5eb5b94/attachment.sig>

From voldermort at hotmail.com  Mon Nov 30 13:42:34 2015
From: voldermort at hotmail.com (Jeremy)
Date: Mon, 30 Nov 2015 06:42:34 -0700 (MST)
Subject: build ghc without ghci libraries?
Message-ID: <1448890954159-5823292.post@n5.nabble.com>

I'm currently removing *.o after building ghc to save space (I don't need
them for what I'm doing). Is there a straightforward way to tell GHC not to
build them in the first place, such as --disable-library-for-ghci does for
cabal, instead of deleting them after the fact? (I do need ghci support for
template haskell.)

To clarify, I'm building GHC itself, not using GHC to build a package.



--
View this message in context: http://haskell.1045720.n5.nabble.com/build-ghc-without-ghci-libraries-tp5823292.html
Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.