Re: Improving the Int/Word story inside GHC

[Carter Schonwald]

would this result in evolving how vector/array indexing works internally to
using Words rather than Ints?


On Thu, Aug 7, 2014 at 5:37 PM, Simon Peyton Jones 
wrote:

>
> | > One thought is that the profiling word appears just *before* the start
> | of a heap object, so that might need a negative offset, but it seems like
> | a rather special case.
> |
> | Hmmm... the profiling word is the second word of the object, after the
> | info pointer.
>
> Oh, OK, I'm mis-remembering that; apols.
>
> Simon
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: ARM64 Task Force

[Karel Gardas]

On 08/ 8/14 01:58 AM, Luke Iannini wrote:

I'm now studying David's patches to LLVM to learn how to add the
ARM64/GHC calling convention to LLVM.


Here is also original ARM/GHC calling convention submission. It's always 
good to have more examples as reference...


http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-October/044173.html

Good luck with the ARM64/GHC porting work!

Karel
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Building GHC under Wine?

[Alexander Kjeldaas]

Microsoft has free VMs for testing purposes. It expires after 90 days and
the only relevant limitation that i see is that it's not licensed for a
"live operating environment".

That might or might not exclude Travis, but scripting a test that
developers can run personally should be allowed.

https://www.modern.ie/en-us/virtualization-tools

Alexander
On Aug 8, 2014 5:14 AM, "Mateusz Kowalczyk"  wrote:

> On 07/16/2014 12:55 AM, Joachim Breitner wrote:
> > Hi,
> >
> > I feel sorry for Simon always repeatedly stuck with an unbuildable tree,
> > and an idea crossed my mind: Can we build¹ GHC under Wine? If so, is it
> > likely to catch the kind of problems that Simon is getting? If so, maybe
> > it runs fast enough to be also tested by travis on every commit?
> >
> > (This mail is to find out if people have tried it before. If not, I’ll
> > give it a quick shot.)
> >
> > Greetings,
> > Joachim
> >
> > ¹ we surely can use it:
> http://www.haskell.org/haskellwiki/GHC_under_Wine
> >
> >
>
> Perhaps this is a bit off-tangent but few months ago there were some
> commits landing to the nix package manager which allow you to run tests
> in a Windows VM. It was created to run tests for things like
> cross-compiled packages but it probably could be adapted.
>
> If you don't mind actually installing Windows (in a VM) and have nix
> already/plan on using it then that might be a more preferable workflow:
> create a nix expression that builds a validates GHC in the VM and spits
> out the result.
>
> It's just something I thought I should mention in case anyone was
> interested.
>
> --
> Mateusz K.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Building GHC under Wine?

[Luite Stegeman]

Yes it's a regular Windows installation, it just comes with an "IEUser"
account preinstalled. I've been using it to test GHCJS on Windows (but not
for automatic builds yet, just manual test runs).

luite



On Fri, Aug 8, 2014 at 7:27 AM, Mateusz Kowalczyk 
wrote:

> On 08/08/2014 07:21 AM, Alexander Kjeldaas wrote:
> > Microsoft has free VMs for testing purposes. It expires after 90 days and
> > the only relevant limitation that i see is that it's not licensed for a
> > "live operating environment".
> >
> > That might or might not exclude Travis, but scripting a test that
> > developers can run personally should be allowed.
> >
> > https://www.modern.ie/en-us/virtualization-tools
> >
> > Alexander
>
> This seems to be a VM dedicated for running Internet Explorer, is it
> actually a fully-featured environment? The site doesn't show much info.
>
> > On Aug 8, 2014 5:14 AM, "Mateusz Kowalczyk" 
> wrote:
> >
> >> On 07/16/2014 12:55 AM, Joachim Breitner wrote:
> >>> Hi,
> >>>
> >>> I feel sorry for Simon always repeatedly stuck with an unbuildable
> tree,
> >>> and an idea crossed my mind: Can we build¹ GHC under Wine? If so, is it
> >>> likely to catch the kind of problems that Simon is getting? If so,
> maybe
> >>> it runs fast enough to be also tested by travis on every commit?
> >>>
> >>> (This mail is to find out if people have tried it before. If not, I’ll
> >>> give it a quick shot.)
> >>>
> >>> Greetings,
> >>> Joachim
> >>>
> >>> ¹ we surely can use it:
> >> http://www.haskell.org/haskellwiki/GHC_under_Wine
> >>>
> >>>
> >>
> >> Perhaps this is a bit off-tangent but few months ago there were some
> >> commits landing to the nix package manager which allow you to run tests
> >> in a Windows VM. It was created to run tests for things like
> >> cross-compiled packages but it probably could be adapted.
> >>
> >> If you don't mind actually installing Windows (in a VM) and have nix
> >> already/plan on using it then that might be a more preferable workflow:
> >> create a nix expression that builds a validates GHC in the VM and spits
> >> out the result.
> >>
> >> It's just something I thought I should mention in case anyone was
> >> interested.
> >>
> >> --
> >> Mateusz K.
> >> ___
> >> ghc-devs mailing list
> >> ghc-devs@haskell.org
> >> http://www.haskell.org/mailman/listinfo/ghc-devs
> >>
> >
>
>
> --
> Mateusz K.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Building GHC under Wine?

[Alexander Kjeldaas]

On Aug 8, 2014 7:27 AM, "Mateusz Kowalczyk"  wrote:
>
> On 08/08/2014 07:21 AM, Alexander Kjeldaas wrote:
> > Microsoft has free VMs for testing purposes. It expires after 90 days
and
> > the only relevant limitation that i see is that it's not licensed for a
> > "live operating environment".
> >
> > That might or might not exclude Travis, but scripting a test that
> > developers can run personally should be allowed.
> >
> > https://www.modern.ie/en-us/virtualization-tools
> >
> > Alexander
>
> This seems to be a VM dedicated for running Internet Explorer, is it
> actually a fully-featured environment? The site doesn't show much info.

I don't know as I haven't used it. However, developing for any browser
these days can include native code, GPGPU etc, so I don't expect it to be
severely crippled.

Alexander

>
> > On Aug 8, 2014 5:14 AM, "Mateusz Kowalczyk" 
wrote:
> >
> >> On 07/16/2014 12:55 AM, Joachim Breitner wrote:
> >>> Hi,
> >>>
> >>> I feel sorry for Simon always repeatedly stuck with an unbuildable
tree,
> >>> and an idea crossed my mind: Can we build¹ GHC under Wine? If so, is
it
> >>> likely to catch the kind of problems that Simon is getting? If so,
maybe
> >>> it runs fast enough to be also tested by travis on every commit?
> >>>
> >>> (This mail is to find out if people have tried it before. If not, I’ll
> >>> give it a quick shot.)
> >>>
> >>> Greetings,
> >>> Joachim
> >>>
> >>> ¹ we surely can use it:
> >> http://www.haskell.org/haskellwiki/GHC_under_Wine
> >>>
> >>>
> >>
> >> Perhaps this is a bit off-tangent but few months ago there were some
> >> commits landing to the nix package manager which allow you to run tests
> >> in a Windows VM. It was created to run tests for things like
> >> cross-compiled packages but it probably could be adapted.
> >>
> >> If you don't mind actually installing Windows (in a VM) and have nix
> >> already/plan on using it then that might be a more preferable workflow:
> >> create a nix expression that builds a validates GHC in the VM and spits
> >> out the result.
> >>
> >> It's just something I thought I should mention in case anyone was
> >> interested.
> >>
> >> --
> >> Mateusz K.
> >> ___
> >> ghc-devs mailing list
> >> ghc-devs@haskell.org
> >> http://www.haskell.org/mailman/listinfo/ghc-devs
> >>
> >
>
>
> --
> Mateusz K.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Building GHC under Wine?

[Mateusz Kowalczyk]

On 08/08/2014 07:21 AM, Alexander Kjeldaas wrote:
> Microsoft has free VMs for testing purposes. It expires after 90 days and
> the only relevant limitation that i see is that it's not licensed for a
> "live operating environment".
> 
> That might or might not exclude Travis, but scripting a test that
> developers can run personally should be allowed.
> 
> https://www.modern.ie/en-us/virtualization-tools
> 
> Alexander

This seems to be a VM dedicated for running Internet Explorer, is it
actually a fully-featured environment? The site doesn't show much info.

> On Aug 8, 2014 5:14 AM, "Mateusz Kowalczyk"  wrote:
> 
>> On 07/16/2014 12:55 AM, Joachim Breitner wrote:
>>> Hi,
>>>
>>> I feel sorry for Simon always repeatedly stuck with an unbuildable tree,
>>> and an idea crossed my mind: Can we build¹ GHC under Wine? If so, is it
>>> likely to catch the kind of problems that Simon is getting? If so, maybe
>>> it runs fast enough to be also tested by travis on every commit?
>>>
>>> (This mail is to find out if people have tried it before. If not, I’ll
>>> give it a quick shot.)
>>>
>>> Greetings,
>>> Joachim
>>>
>>> ¹ we surely can use it:
>> http://www.haskell.org/haskellwiki/GHC_under_Wine
>>>
>>>
>>
>> Perhaps this is a bit off-tangent but few months ago there were some
>> commits landing to the nix package manager which allow you to run tests
>> in a Windows VM. It was created to run tests for things like
>> cross-compiled packages but it probably could be adapted.
>>
>> If you don't mind actually installing Windows (in a VM) and have nix
>> already/plan on using it then that might be a more preferable workflow:
>> create a nix expression that builds a validates GHC in the VM and spits
>> out the result.
>>
>> It's just something I thought I should mention in case anyone was
>> interested.
>>
>> --
>> Mateusz K.
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
> 


-- 
Mateusz K.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Moving Haddock *development* out of GHC tree

[Mateusz Kowalczyk]

Hello,

A slightly long e-mail but I ask that you voice your opinion if you ever
changed GHC API. You can skim over the details, simply know that it
saves me vast amount of time, allows me to try and find contributors and
doesn't impact GHC negatively. It seems like a win-win scenario for GHC
and Haddock. GHC team's workflow does not change and will not require
any new commitment: I do all the work and I think it's a 1 line change
in sync-all when transition is ready. Here it is:


It is no secret that many core Haskell projects lack developer hands and
Haddock is no exception: the current maintainers are Simon Hengel and
myself. Simon does not have much time so currently all the issues and
updates are up to me. Ideally I would like if some more people could
come and hack on Haddock but there are a couple of problems with trying
to recruit folk for this:

1. Interacting with GHC API is not the easiest thing. This is Haddock's
problem but I thought I'd mention it here.

2. Haddock resides directly in the GHC tree and it is currently
*required* that it compiles with GHC HEAD. This is a huge barrier of
entry for anyone: today I wanted to make a fairly simple change but it
still took me 3 validate runs to be at least somewhat confident that I
didn't break much in GHC. On top of this I had help from Edward Z. Yang
on IRC and information from him on what the issue exactly was. If I was
to do everything alone it would have taken even more validates. A
validate is not fast on machine by any means, it takes an hour or two.

Here is what I want to do unless there are major objections: I want to
move the active development away from GHC tree. Below is how it would
work. For simplicity please imagine that we have *just* released 7.8.3.

* Haddock development would concentrate on supporting the last public
release of GHC: I stop developing against GHC HEAD and currently would
develop against 7.8.3.

* GHC itself checks out Haddock as a submodule as it does now. The only
difference is that it points at whatever commit worked last. Let us
assume it is the Haddock 2.14.3 release commit. The vital difference
from current state is that GHC will no longer track changes in master
branch.

* Now when GHC API changes things proceed as they normally do: whoever
is responsible for the changes, pops into the Haddock submodule applies
the patches necessary for Haddock to build with HEAD and everyone is
happy. What does *not* happen is these patches don't go into master: I
ignore them and keep working with 7.8.3.

* When a GHC release rolls around, I update Haddock to work with the new
API so that people with new release can still use it. Once it works
against new API, GHC can start tracking from that commit onwards and
proceed as usual.

Here are the advantages:

* I don't have to work against GHC HEAD. This means I don't have to
build GHC HEAD and I don't need to worry about GHC API changes. I don't
waste 2-4 hours building before hacking and validating after hacking to
make any minor changes and to make sure I haven't broken anything.

* More importantly, anyone who wants to write a patch for Haddock can
now do so easily, all they need is recent compiler rather than being
forced to build HEAD. Building and validating against HEAD is a **huge**
barrier of entry.

* I only have to care about GHC API changes once a release and not twice
a week. I think PatternSynonyms have changed 4 times in a month but the
end result at release time is the same and that's what people care about.

* It is less work for anyone changing GHC API: they only have to deal
with their own changes and not my changes which add features or whatever.

* If I break something in Haddock HEAD, GHC is not affected.

* If Haddock's binary interface doesn't change, we may even allow more
versions of GHC be compatible through CPP and other such trickery. If we
were to do it today, it would be an increased burden on the GHC team to
deal with those.

* I can release as often as I want against the same compiler version.
Currently doing this requires backporting features (see v2.14 branch)
which is a massive pain. I no longer have to tell the users ‘yes, your
bug is fixed but to get it you need to compile GHC HEAD or wait 6-12
months until next GHC release’. I have to do this a lot.

Here are the disadvantages and why I think they don't make a big difference:

* GHC HEAD doesn't get any new-and-cool features that we might
implement. I say this doesn't matter because no one uses varying GHC
HEAD versions to develop actual software, documentation and all. What I
mean to say is that the only user of the Haddock that's developed in GHC
tree is GHC itself. The only case where GHC actually used in-tree
Haddock was when Herbert generated documentation for base-4.7 early for
me to eye before the release. Even this doesn't matter because so close
to the release I'll already have the existing GHC API integrated anyway.
Again, it does not matter if GHC HEAD itself doesn't get pretty

Re: Building GHC under Wine?

[Mateusz Kowalczyk]

On 07/16/2014 12:55 AM, Joachim Breitner wrote:
> Hi,
> 
> I feel sorry for Simon always repeatedly stuck with an unbuildable tree,
> and an idea crossed my mind: Can we build¹ GHC under Wine? If so, is it
> likely to catch the kind of problems that Simon is getting? If so, maybe
> it runs fast enough to be also tested by travis on every commit?
> 
> (This mail is to find out if people have tried it before. If not, I’ll
> give it a quick shot.)
> 
> Greetings,
> Joachim
> 
> ¹ we surely can use it: http://www.haskell.org/haskellwiki/GHC_under_Wine
> 
> 

Perhaps this is a bit off-tangent but few months ago there were some
commits landing to the nix package manager which allow you to run tests
in a Windows VM. It was created to run tests for things like
cross-compiled packages but it probably could be adapted.

If you don't mind actually installing Windows (in a VM) and have nix
already/plan on using it then that might be a more preferable workflow:
create a nix expression that builds a validates GHC in the VM and spits
out the result.

It's just something I thought I should mention in case anyone was
interested.

-- 
Mateusz K.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: ARM64 Task Force

[Luke Iannini]

Hi all,

An update on this -- I've made a bit of progress thanks to Karel and Colin's
start at ARM64 support
https://ghc.haskell.org/trac/ghc/ticket/7942
With a few tweaks*, that let me build a GHC that builds ARM64 binaries and
load them onto my iPad Air, which is great! But of course they don't work
yet since LLVM doesn't have the ARM64/GHC calling convention in.

Happily I was able to use LLVM HEAD to do this, which means we don't need
to be bound to Xcode's release schedules.

I'm now studying David's patches to LLVM to learn how to add the ARM64/GHC
calling convention to LLVM.

*including Ben Gamari's patches to get LLVM HEAD working
https://github.com/bgamari/ghc/tree/llvm-3.5-new

Best
Luke


On Mon, Jul 7, 2014 at 11:06 PM, Luke Iannini  wrote:

> Howdy all,
>
> Would anyone like to team up on getting ARM64 support into GHC?
>
> Cheers
> Luke
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: arc diff linter looping / stuck

[Simon Peyton Jones]

I'm off on holiday for a week, but you and I have discussed most of these 
changes, some at length. If you are happy with your implementation, then go 
ahead and commit, from my pov.

I did take a quick look though.  For #9200 and TcTyClsDecls, I think you have 
implemented "Possible new strategy" on 
https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference, but not "A 
possible variation" (same page).  correct?  If so, worth a note in the source 
code. And actually I'd transfer the algorithm itself, including the definition 
of CUSK, into the code. 

kcStrategy seems a very odd name for a predicate on HsDecls that is just a Bool 
saying whether or not it has a CUSK.  Also odd is that every call to 
kcHsTyVarBndrs has a corresponding call to kcStrategy, and both functions are 
in TcHsType; why not just combine them into one?

Thanks for doing this

Simon

| -Original Message-
| From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Richard
| Eisenberg
| Sent: 07 August 2014 19:34
| To: ghc-devs
| Subject: arc diff linter looping / stuck
| 
| Hi all,
| 
| I've prepared a bunch of commits to fix several tickets. After pushing
| these commits to branch wip/rae (to save my place and to get validate
| running on Travis), I then `git checkout`ed back to a point where `git
| diff origin/master` gave me a patch for precisely one bug (instead of the
| several unrelated ones I had fixed). I wanted to post to Differential.
| `arc diff` allowed me to fill out a description message (which mentioned,
| in its comments, the right set of commits), but then hung on the
| "linting..." stage. I suppose I could skip the linter, but it's more
| likely I've done something wrong here...
| 
| Any advice?
| 
| In the meantime, please consider this to be a request for feedback on
| everything in wip/rae! The bugs fixed are #9200, #9415, #9404, and #9371.
| 
| Thanks!
| Richard
| ___
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Improving the Int/Word story inside GHC

[Simon Peyton Jones]

| > One thought is that the profiling word appears just *before* the start
| of a heap object, so that might need a negative offset, but it seems like
| a rather special case.
| 
| Hmmm... the profiling word is the second word of the object, after the
| info pointer.

Oh, OK, I'm mis-remembering that; apols.

Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Improving the Int/Word story inside GHC

[Simon Marlow]

On 07/08/14 16:01, Johan Tibell wrote:

On Thu, Aug 7, 2014 at 4:36 PM, Simon Marlow  wrote:

I think doing the comparison with Integer is the right fix.  Relying on Word
being big enough for these things is technically wrong because we might be
cross-compiling from a smaller word size.


That sounds like an easier fix and I will try that. Unfortunately
working with Integers means lots of our convenience functions, such as
wordsToBytes, go out the window, as the all work on Byte/WordOff.
Here's an example that now gets more annoying:

 shouldInlinePrimOp dflags NewArrayOp [(CmmLit (CmmInt n _)), init]
   | wordsToBytes dflags (fromInteger n) <= maxInlineAllocSize dflags =


Maybe wordsToBytes should be overloaded on Integral (with specialisations).

Cheers,
Simon


Most of our array primops are likely* still wrong, as the code that
generates them uses Int everywhere. Still also sounds like a problem
for cross-compiling.

* In some cases we might be lucky and the Int is never introspected
any we just look at the bits (i.e. pretend it's a Word) when we
generate code.



___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Improving the Int/Word story inside GHC

[Simon Marlow]

On 07/08/14 15:45, Simon Peyton Jones wrote:

When I introduced them in the first place they were used for positive offsets 
within StackAreas and heap objects.  Both are organised with the zeroth byte of 
the stack area or heap object being at the lowest address.

It's true that a positive offset from the beginning of a block of contiguous 
freshly-allocated heap objects will turn into a negative displacement from the 
actual, physical heap pointer.  If ByteOff is used for both purpose then yes 
there will be negative ones.

>

More than that I cannot say.  They may well be being used for other purposes by 
now.


I'm hazy on the history but I'm sure you're right.  In any case I'm 
pretty sure I've used these types in lots of places.



One thought is that the profiling word appears just *before* the start of a 
heap object, so that might need a negative offset, but it seems like a rather 
special case.


Hmmm... the profiling word is the second word of the object, after the 
info pointer.


Cheers,
Simon


Simon

| -Original Message-
| From: Simon Marlow [mailto:marlo...@gmail.com]
| Sent: 07 August 2014 15:26
| To: Simon Peyton Jones; Johan Tibell
| Cc: ghc-devs@haskell.org
| Subject: Re: Improving the Int/Word story inside GHC
|
| Hmm, surely these are used for negative offsets a lot?  All Hp-relative
| indices are negative (but virtual Hp offsets are positive), and Sp-
| relative indices can be both negative and positive.
|
| On 07/08/2014 12:49, Simon Peyton Jones wrote:
| > I’m all for it!
| >
| > I believe that ByteOff/WordOff are always 0 or positive.   At least,
| > they were when I introduced them!
| >
| > SImon
| >
| > *From:*ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of
| > *Johan Tibell
| > *Sent:* 07 August 2014 12:21
| > *To:* Simon Marlow
| > *Cc:* ghc-devs@haskell.org
| > *Subject:* Re: Improving the Int/Word story inside GHC
| >
| > Simon M, is the intention of ByteOff and WordOff that they should be
| > able to represent negative quantities as well? If so we might need to
| > split it into ByteOff (still an Int) and ByteIndex (a Word) to have a
| > type for indexing into arrays.
| >
| > On Thu, Aug 7, 2014 at 1:16 PM, Edward Z. Yang  > wrote:
| >
| > If it's strictly just in the codegen (and not affecting user
| code),
| > seems fine to me.
| >
| > Edward
| >
| > Excerpts from Johan Tibell's message of 2014-08-07 12:10:37
| +0100:
| >
| >  > Inside GHC we mostly use Int instead of Word, even when we
| want to
| >  > represent non-negative values, such as sizes of things or
| indices
| > into
| >  > things. This is now causing some grief in
| >  > https://ghc.haskell.org/trac/ghc/ticket/9416, where an
| allocation
| > boundary
| >  > case test fails with a segfault because a n < m Int comparison
| > overflows.
| >  >
| >  > I tried to fix the issue by changing the type of
| > maxInlineAllocSize, which
| >  > is used on one side of the above comparison, to Word. However,
| that
| >  > unravels a bunch of other issues, such as wordsToBytes,
| ByteOff,
| > etc are
| >  > all Int-valued quantities.
| >  >
| >  > I could perhaps work around these problems by judicious use of
| > fromIntegral
| >  > in StgCmmPrim, but I'm a bit unhappy about it because it 1)
| makes
| > the code
| >  > uglier and 2) needs to be done in quite a few places.
| >  >
| >  > How much work would it be to try to switch the codegen to use
| > Word for most
| >  > of these quantities instead?
| >  >
| >  > -- Johan
| >



___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

arc diff linter looping / stuck

[Richard Eisenberg]

Hi all,

I've prepared a bunch of commits to fix several tickets. After pushing these 
commits to branch wip/rae (to save my place and to get validate running on 
Travis), I then `git checkout`ed back to a point where `git diff origin/master` 
gave me a patch for precisely one bug (instead of the several unrelated ones I 
had fixed). I wanted to post to Differential. `arc diff` allowed me to fill out 
a description message (which mentioned, in its comments, the right set of 
commits), but then hung on the "linting..." stage. I suppose I could skip the 
linter, but it's more likely I've done something wrong here...

Any advice?

In the meantime, please consider this to be a request for feedback on 
everything in wip/rae! The bugs fixed are #9200, #9415, #9404, and #9371.

Thanks!
Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

biographical profiling is broken?

[Ömer Sinan Ağacan]

Hi all,

I'm trying to use LDV profiling features of GHC but I'm failing.
Here's what I try:

(I'm using GHC 7.8.2)

* I'm compiling my app with `-prof` and I'm also using `-fprof-auto`
just to be sure.
* I'm running my app using `+RTS -hbdrag,void` as described in the
docs. 
(https://www.haskell.org/ghc/docs/latest/html/users_guide/prof-heap.html#biography-prof)

This always generates an empty MyApp.hp file. There's only this header
in the generated file:

  JOB "MyApp +RTS -hd -hbdrag,void,lag"
  DATE "Thu Aug  7 18:14 2014"
  SAMPLE_UNIT "seconds"
  VALUE_UNIT "bytes"
  BEGIN_SAMPLE 0.00
  END_SAMPLE 0.00
  BEGIN_SAMPLE 0.10
  END_SAMPLE 0.10

I tried different programs, from "hello world" to a complex language
interpreter. I always get the same file with only a header.

* I also tried adding more arguments like `-hc`, `-hm`, `-hr` etc. but
I got same results.

I feel like the feature is broken. I checked the test suite to find
some working LDV profiling programs. But as far as I can see we don't
have any tests for LDV stuff. There's a `bio001.stdout` which I
believe is related with "biographical profiling"(which means LDV) but
again AFAICS it's not used.

(I'm not having any different behaviors or exceptions while running
programs using LDV RTS arguments.)

Can anyone help me with this? Is anyone using this feature? Am I right
that this feature is not tested?

Thanks.

---
Ömer Sinan Ağacan
http://osa1.net
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Improving the Int/Word story inside GHC

[Johan Tibell]

On Thu, Aug 7, 2014 at 4:36 PM, Simon Marlow  wrote:
> I think doing the comparison with Integer is the right fix.  Relying on Word
> being big enough for these things is technically wrong because we might be
> cross-compiling from a smaller word size.

That sounds like an easier fix and I will try that. Unfortunately
working with Integers means lots of our convenience functions, such as
wordsToBytes, go out the window, as the all work on Byte/WordOff.
Here's an example that now gets more annoying:

shouldInlinePrimOp dflags NewArrayOp [(CmmLit (CmmInt n _)), init]
  | wordsToBytes dflags (fromInteger n) <= maxInlineAllocSize dflags =

Most of our array primops are likely* still wrong, as the code that
generates them uses Int everywhere. Still also sounds like a problem
for cross-compiling.

* In some cases we might be lucky and the Int is never introspected
any we just look at the bits (i.e. pretend it's a Word) when we
generate code.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Overlapping and incoherent instances

[Stephen Paul Weber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

>I suppose that -XOverlappingInstances could mean "silently honour 
>OVERLAPPABLE/OVERLAPPING pragmas", while lacking it would mean "honour 
>OVERLAPPABLE/OVERLAPPING pragmas, but emit noisy warnings" or even "don't 
>honour them and warn".
>
>But that is different to the behaviour today, so we'd need a new LANGUAGE 
>pragma.  Perhaps -XHonourOverlappingInstances or something.

This would be a reasonable alternative to the keyword-based solution.  At 
least for now.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJT45F5AAoJENEcKRHOUZzewwwQALUiK60sbIC6j5nbXHPCeau8
bN80pmhUL11lAyI7OCSQyV8S9AU7ikgaUPyKwk/cx/TtKQGLwghWFZlRCoCRrplk
dmGsSCw2LN4GElHL22EcyELPcx74lknz3tmQuZg4oAUXm1h2w8774L3iHOE4Ompg
9gYzuOo8Ii3oHJ6fjIL0DwGWp92F8NrTPeQmziBOPHAgQYVFO8QMncXcOGtdIZUb
PQr0szr9HLkcwKSrYoxvvZBqEj6AM0xj+KhX87NEnQ08EaY6FO/Dhm4mi7X/A5Ca
khwsjwId0qR6C4vs7QyYnaK3yiUFlZMUlXdUhpRG3wWFHseb3m9tX2a2ewE30jPl
TgnoU5NYphijMWXpc3p06D5Zj0lT6L++Y3Ez8CS+0QpBPG9c0CJnLqXFQ5CNbl+9
Ryzpg7ltg5vhtq7BLwcz+V87lzc4KYm/tyqEVvxN59W6XLuLLe4tW6NL9vLDl9Rg
/3vMRYKZBa+0we7jAi/wYbdks7g+9sqpiLqke5m73a5F2j/TTl4BrkIj2vG0KrP+
G9eJC1aieUbfPXXwXWSJh8binJNp//qWs7rILDsx4r0o1QR245uT5WzwkwapXmE8
ZYuXsVcc1/mS1ZneOP6zn0QOlRcUJ0A5dFxQg69hsXpD+MM226r/57P3eI9XhLRN
W+DNBoXbr9mp8eNGjl6O
=CFkA
-END PGP SIGNATURE-
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Improving the Int/Word story inside GHC

[Simon Peyton Jones]

When I introduced them in the first place they were used for positive offsets 
within StackAreas and heap objects.  Both are organised with the zeroth byte of 
the stack area or heap object being at the lowest address.

It's true that a positive offset from the beginning of a block of contiguous 
freshly-allocated heap objects will turn into a negative displacement from the 
actual, physical heap pointer.  If ByteOff is used for both purpose then yes 
there will be negative ones.

More than that I cannot say.  They may well be being used for other purposes by 
now.

One thought is that the profiling word appears just *before* the start of a 
heap object, so that might need a negative offset, but it seems like a rather 
special case.

Simon

| -Original Message-
| From: Simon Marlow [mailto:marlo...@gmail.com]
| Sent: 07 August 2014 15:26
| To: Simon Peyton Jones; Johan Tibell
| Cc: ghc-devs@haskell.org
| Subject: Re: Improving the Int/Word story inside GHC
| 
| Hmm, surely these are used for negative offsets a lot?  All Hp-relative
| indices are negative (but virtual Hp offsets are positive), and Sp-
| relative indices can be both negative and positive.
| 
| On 07/08/2014 12:49, Simon Peyton Jones wrote:
| > I’m all for it!
| >
| > I believe that ByteOff/WordOff are always 0 or positive.   At least,
| > they were when I introduced them!
| >
| > SImon
| >
| > *From:*ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of
| > *Johan Tibell
| > *Sent:* 07 August 2014 12:21
| > *To:* Simon Marlow
| > *Cc:* ghc-devs@haskell.org
| > *Subject:* Re: Improving the Int/Word story inside GHC
| >
| > Simon M, is the intention of ByteOff and WordOff that they should be
| > able to represent negative quantities as well? If so we might need to
| > split it into ByteOff (still an Int) and ByteIndex (a Word) to have a
| > type for indexing into arrays.
| >
| > On Thu, Aug 7, 2014 at 1:16 PM, Edward Z. Yang  > wrote:
| >
| > If it's strictly just in the codegen (and not affecting user
| code),
| > seems fine to me.
| >
| > Edward
| >
| > Excerpts from Johan Tibell's message of 2014-08-07 12:10:37
| +0100:
| >
| >  > Inside GHC we mostly use Int instead of Word, even when we
| want to
| >  > represent non-negative values, such as sizes of things or
| indices
| > into
| >  > things. This is now causing some grief in
| >  > https://ghc.haskell.org/trac/ghc/ticket/9416, where an
| allocation
| > boundary
| >  > case test fails with a segfault because a n < m Int comparison
| > overflows.
| >  >
| >  > I tried to fix the issue by changing the type of
| > maxInlineAllocSize, which
| >  > is used on one side of the above comparison, to Word. However,
| that
| >  > unravels a bunch of other issues, such as wordsToBytes,
| ByteOff,
| > etc are
| >  > all Int-valued quantities.
| >  >
| >  > I could perhaps work around these problems by judicious use of
| > fromIntegral
| >  > in StgCmmPrim, but I'm a bit unhappy about it because it 1)
| makes
| > the code
| >  > uglier and 2) needs to be done in quite a few places.
| >  >
| >  > How much work would it be to try to switch the codegen to use
| > Word for most
| >  > of these quantities instead?
| >  >
| >  > -- Johan
| >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Perf regression: ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) (f686682)

[Simon Marlow]

On 06/08/2014 21:40, Sergei Trofimovich wrote:

I think I know what happens. According to perf the benchmark spends 34%+
of time in garbage collection ('perf record -- $args'/'perf report'):

   27,91%  test  test   [.] evacuate
9,29%  test  test   [.] s9Lz_info
7,46%  test  test   [.] scavenge_block

And the whole benchmark runs a tiny bit more than 300ms.
It is exactly in line with major GC timer (0.3s).


0.3s is the *idle* GC timer, it has no effect when the program is 
running normally.  There's no timed GC or anything like that.


It sometimes happens that a tiny change somewhere tips a program over 
into doing one more major GC, though.



If we run
 $ time ./test inverter 345 10n 4u 1>/dev/null
multiple times there is heavy instability in there (with my patch reverted):
 real0m0.319s
 real0m0.305s
 real0m0.307s
 real0m0.373s
 real0m0.381s
which is +/- 80ms drift!

Let's try to kick major GC earlier instead of running right at runtime
shutdown time:
 $ time ./test inverter 345 10n 4u +RTS -I0.1 1>/dev/null

 real0m0.304s
 real0m0.308s
 real0m0.302s
 real0m0.304s
 real0m0.308s
 real0m0.306s
 real0m0.305s
 real0m0.312s
which is way more stable behaviour.

Thus my theory is that my changed stepped from
   "90% of time 1 GC run per run"
to
   "90% of time 2 GC runs per run"


Is this program idle?  I have no idea why this might be happening!  If 
the program is busy computing stuff, the idle GC should not be firing. 
If it is, that's a bug.


Cheers,
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Improving the Int/Word story inside GHC

[Simon Marlow]

On 07/08/2014 12:10, Johan Tibell wrote:

Inside GHC we mostly use Int instead of Word, even when we want to
represent non-negative values, such as sizes of things or indices into
things. This is now causing some grief in
https://ghc.haskell.org/trac/ghc/ticket/9416, where an allocation
boundary case test fails with a segfault because a n < m Int comparison
overflows.

I tried to fix the issue by changing the type of maxInlineAllocSize,
which is used on one side of the above comparison, to Word. However,
that unravels a bunch of other issues, such as wordsToBytes, ByteOff,
etc are all Int-valued quantities.

>

I could perhaps work around these problems by judicious use of
fromIntegral in StgCmmPrim, but I'm a bit unhappy about it because it 1)
makes the code uglier and 2) needs to be done in quite a few places.


I think doing the comparison with Integer is the right fix.  Relying on 
Word being big enough for these things is technically wrong because we 
might be cross-compiling from a smaller word size.


Cheers,
Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Improving the Int/Word story inside GHC

[Simon Marlow]

Hmm, surely these are used for negative offsets a lot?  All Hp-relative 
indices are negative (but virtual Hp offsets are positive), and 
Sp-relative indices can be both negative and positive.


On 07/08/2014 12:49, Simon Peyton Jones wrote:

I’m all for it!

I believe that ByteOff/WordOff are always 0 or positive.   At least,
they were when I introduced them!

SImon

*From:*ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of
*Johan Tibell
*Sent:* 07 August 2014 12:21
*To:* Simon Marlow
*Cc:* ghc-devs@haskell.org
*Subject:* Re: Improving the Int/Word story inside GHC

Simon M, is the intention of ByteOff and WordOff that they should be
able to represent negative quantities as well? If so we might need to
split it into ByteOff (still an Int) and ByteIndex (a Word) to have a
type for indexing into arrays.

On Thu, Aug 7, 2014 at 1:16 PM, Edward Z. Yang mailto:ezy...@mit.edu>> wrote:

If it's strictly just in the codegen (and not affecting user code),
seems fine to me.

Edward

Excerpts from Johan Tibell's message of 2014-08-07 12:10:37 +0100:

 > Inside GHC we mostly use Int instead of Word, even when we want to
 > represent non-negative values, such as sizes of things or indices
into
 > things. This is now causing some grief in
 > https://ghc.haskell.org/trac/ghc/ticket/9416, where an allocation
boundary
 > case test fails with a segfault because a n < m Int comparison
overflows.
 >
 > I tried to fix the issue by changing the type of
maxInlineAllocSize, which
 > is used on one side of the above comparison, to Word. However, that
 > unravels a bunch of other issues, such as wordsToBytes, ByteOff,
etc are
 > all Int-valued quantities.
 >
 > I could perhaps work around these problems by judicious use of
fromIntegral
 > in StgCmmPrim, but I'm a bit unhappy about it because it 1) makes
the code
 > uglier and 2) needs to be done in quite a few places.
 >
 > How much work would it be to try to switch the codegen to use
Word for most
 > of these quantities instead?
 >
 > -- Johan


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Improving the Int/Word story inside GHC

[Johan Tibell]

I've uploaded https://phabricator.haskell.org/D125 to give an idea of what
such a change might look like. I'm not quite done with the change (it's
quite a chore) but the commit gives and idea of what such a change might
look like.

I'm still not convinced that making ByteOff a Word is the right thing,
there seems to be several cases where it's used to represent a negative
offset.


On Thu, Aug 7, 2014 at 3:53 PM, Johan Tibell  wrote:

> I guess this example, from mk_switch in StgCmmUtils, is the same
>
> return (mkSwitch (cmmOffset dflags tag_expr (- real_lo_tag)) arms)
>
> ?
>
> (This is clearly a negative offset and I don't know the implications of
> the Cmm code we output if we switch to ByteOff = Word)
>
>
> On Thu, Aug 7, 2014 at 3:49 PM, Edward Z. Yang  wrote:
>
>> Yes, in particular if the offset is zero.  Morally, however, we're
>> just doing this to clear the tag bit.
>>
>> Edward
>>
>> Excerpts from Johan Tibell's message of 2014-08-07 14:45:43 +0100:
>> > I'm hacking on this now. I'm not 100% sure that ByteOff isn't used for
>> > negative values though, see for example
>> >
>> > mkTaggedObjectLoad
>> >   :: DynFlags -> LocalReg -> LocalReg -> ByteOff -> DynTag -> CmmAGraph
>> > -- (loadTaggedObjectField reg base off tag) generates assignment
>> > --  reg = bitsK[ base + off - tag ]
>> > -- where K is fixed by 'reg'
>> > mkTaggedObjectLoad dflags reg base offset tag
>> >   = mkAssign (CmmLocal reg)
>> >  (CmmLoad (cmmOffsetB dflags
>> >   (CmmReg (CmmLocal base))
>> >   (offset - tag))
>> >   (localRegType reg))
>> >
>> > from StgCmmUtils.
>> >
>> > Wouldn't it be possible that the offset in cmmOffsetB (which is of type
>> > ByteOff) could be negative?
>> >
>> >
>> >
>> > On Thu, Aug 7, 2014 at 1:49 PM, Simon Peyton Jones <
>> simo...@microsoft.com>
>> > wrote:
>> >
>> > >  I’m all for it!
>> > >
>> > >
>> > >
>> > > I believe that ByteOff/WordOff are always 0 or positive.   At least,
>> they
>> > > were when I introduced them!
>> > >
>> > >
>> > >
>> > > SImon
>> > >
>> > >
>> > >
>> > > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of
>> *Johan
>> > > Tibell
>> > > *Sent:* 07 August 2014 12:21
>> > > *To:* Simon Marlow
>> > > *Cc:* ghc-devs@haskell.org
>> > > *Subject:* Re: Improving the Int/Word story inside GHC
>> > >
>> > >
>> > >
>> > > Simon M, is the intention of ByteOff and WordOff that they should be
>> able
>> > > to represent negative quantities as well? If so we might need to
>> split it
>> > > into ByteOff (still an Int) and ByteIndex (a Word) to have a type for
>> > > indexing into arrays.
>> > >
>> > >
>> > >
>> > > On Thu, Aug 7, 2014 at 1:16 PM, Edward Z. Yang 
>> wrote:
>> > >
>> > >  If it's strictly just in the codegen (and not affecting user code),
>> > > seems fine to me.
>> > >
>> > > Edward
>> > >
>> > > Excerpts from Johan Tibell's message of 2014-08-07 12:10:37 +0100:
>> > >
>> > > > Inside GHC we mostly use Int instead of Word, even when we want to
>> > > > represent non-negative values, such as sizes of things or indices
>> into
>> > > > things. This is now causing some grief in
>> > > > https://ghc.haskell.org/trac/ghc/ticket/9416, where an allocation
>> > > boundary
>> > > > case test fails with a segfault because a n < m Int comparison
>> overflows.
>> > > >
>> > > > I tried to fix the issue by changing the type of maxInlineAllocSize,
>> > > which
>> > > > is used on one side of the above comparison, to Word. However, that
>> > > > unravels a bunch of other issues, such as wordsToBytes, ByteOff,
>> etc are
>> > > > all Int-valued quantities.
>> > > >
>> > > > I could perhaps work around these problems by judicious use of
>> > > fromIntegral
>> > > > in StgCmmPrim, but I'm a bit unhappy about it because it 1) makes
>> the
>> > > code
>> > > > uglier and 2) needs to be done in quite a few places.
>> > > >
>> > > > How much work would it be to try to switch the codegen to use Word
>> for
>> > > most
>> > > > of these quantities instead?
>> > > >
>> > > > -- Johan
>> > >
>> > >
>> > >
>>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

New docs about tracking down regressions in GHC

[Edward Z . Yang]

I recently spent some time debugging a performance regression in
Haddock, and came up with some useful tips and tricks for tracking
these things down in GHC.  I wrote them up here:

https://ghc.haskell.org/trac/ghc/wiki/Debugging/ProfilingGhc

Please take a look.

Thanks,
Edward
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Improving the Int/Word story inside GHC

[Johan Tibell]

I guess this example, from mk_switch in StgCmmUtils, is the same

return (mkSwitch (cmmOffset dflags tag_expr (- real_lo_tag)) arms)

?

(This is clearly a negative offset and I don't know the implications of the
Cmm code we output if we switch to ByteOff = Word)


On Thu, Aug 7, 2014 at 3:49 PM, Edward Z. Yang  wrote:

> Yes, in particular if the offset is zero.  Morally, however, we're
> just doing this to clear the tag bit.
>
> Edward
>
> Excerpts from Johan Tibell's message of 2014-08-07 14:45:43 +0100:
> > I'm hacking on this now. I'm not 100% sure that ByteOff isn't used for
> > negative values though, see for example
> >
> > mkTaggedObjectLoad
> >   :: DynFlags -> LocalReg -> LocalReg -> ByteOff -> DynTag -> CmmAGraph
> > -- (loadTaggedObjectField reg base off tag) generates assignment
> > --  reg = bitsK[ base + off - tag ]
> > -- where K is fixed by 'reg'
> > mkTaggedObjectLoad dflags reg base offset tag
> >   = mkAssign (CmmLocal reg)
> >  (CmmLoad (cmmOffsetB dflags
> >   (CmmReg (CmmLocal base))
> >   (offset - tag))
> >   (localRegType reg))
> >
> > from StgCmmUtils.
> >
> > Wouldn't it be possible that the offset in cmmOffsetB (which is of type
> > ByteOff) could be negative?
> >
> >
> >
> > On Thu, Aug 7, 2014 at 1:49 PM, Simon Peyton Jones <
> simo...@microsoft.com>
> > wrote:
> >
> > >  I’m all for it!
> > >
> > >
> > >
> > > I believe that ByteOff/WordOff are always 0 or positive.   At least,
> they
> > > were when I introduced them!
> > >
> > >
> > >
> > > SImon
> > >
> > >
> > >
> > > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of
> *Johan
> > > Tibell
> > > *Sent:* 07 August 2014 12:21
> > > *To:* Simon Marlow
> > > *Cc:* ghc-devs@haskell.org
> > > *Subject:* Re: Improving the Int/Word story inside GHC
> > >
> > >
> > >
> > > Simon M, is the intention of ByteOff and WordOff that they should be
> able
> > > to represent negative quantities as well? If so we might need to split
> it
> > > into ByteOff (still an Int) and ByteIndex (a Word) to have a type for
> > > indexing into arrays.
> > >
> > >
> > >
> > > On Thu, Aug 7, 2014 at 1:16 PM, Edward Z. Yang  wrote:
> > >
> > >  If it's strictly just in the codegen (and not affecting user code),
> > > seems fine to me.
> > >
> > > Edward
> > >
> > > Excerpts from Johan Tibell's message of 2014-08-07 12:10:37 +0100:
> > >
> > > > Inside GHC we mostly use Int instead of Word, even when we want to
> > > > represent non-negative values, such as sizes of things or indices
> into
> > > > things. This is now causing some grief in
> > > > https://ghc.haskell.org/trac/ghc/ticket/9416, where an allocation
> > > boundary
> > > > case test fails with a segfault because a n < m Int comparison
> overflows.
> > > >
> > > > I tried to fix the issue by changing the type of maxInlineAllocSize,
> > > which
> > > > is used on one side of the above comparison, to Word. However, that
> > > > unravels a bunch of other issues, such as wordsToBytes, ByteOff, etc
> are
> > > > all Int-valued quantities.
> > > >
> > > > I could perhaps work around these problems by judicious use of
> > > fromIntegral
> > > > in StgCmmPrim, but I'm a bit unhappy about it because it 1) makes the
> > > code
> > > > uglier and 2) needs to be done in quite a few places.
> > > >
> > > > How much work would it be to try to switch the codegen to use Word
> for
> > > most
> > > > of these quantities instead?
> > > >
> > > > -- Johan
> > >
> > >
> > >
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Improving the Int/Word story inside GHC

[Edward Z . Yang]

Yes, in particular if the offset is zero.  Morally, however, we're
just doing this to clear the tag bit.

Edward

Excerpts from Johan Tibell's message of 2014-08-07 14:45:43 +0100:
> I'm hacking on this now. I'm not 100% sure that ByteOff isn't used for
> negative values though, see for example
> 
> mkTaggedObjectLoad
>   :: DynFlags -> LocalReg -> LocalReg -> ByteOff -> DynTag -> CmmAGraph
> -- (loadTaggedObjectField reg base off tag) generates assignment
> --  reg = bitsK[ base + off - tag ]
> -- where K is fixed by 'reg'
> mkTaggedObjectLoad dflags reg base offset tag
>   = mkAssign (CmmLocal reg)
>  (CmmLoad (cmmOffsetB dflags
>   (CmmReg (CmmLocal base))
>   (offset - tag))
>   (localRegType reg))
> 
> from StgCmmUtils.
> 
> Wouldn't it be possible that the offset in cmmOffsetB (which is of type
> ByteOff) could be negative?
> 
> 
> 
> On Thu, Aug 7, 2014 at 1:49 PM, Simon Peyton Jones 
> wrote:
> 
> >  I’m all for it!
> >
> >
> >
> > I believe that ByteOff/WordOff are always 0 or positive.   At least, they
> > were when I introduced them!
> >
> >
> >
> > SImon
> >
> >
> >
> > *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Johan
> > Tibell
> > *Sent:* 07 August 2014 12:21
> > *To:* Simon Marlow
> > *Cc:* ghc-devs@haskell.org
> > *Subject:* Re: Improving the Int/Word story inside GHC
> >
> >
> >
> > Simon M, is the intention of ByteOff and WordOff that they should be able
> > to represent negative quantities as well? If so we might need to split it
> > into ByteOff (still an Int) and ByteIndex (a Word) to have a type for
> > indexing into arrays.
> >
> >
> >
> > On Thu, Aug 7, 2014 at 1:16 PM, Edward Z. Yang  wrote:
> >
> >  If it's strictly just in the codegen (and not affecting user code),
> > seems fine to me.
> >
> > Edward
> >
> > Excerpts from Johan Tibell's message of 2014-08-07 12:10:37 +0100:
> >
> > > Inside GHC we mostly use Int instead of Word, even when we want to
> > > represent non-negative values, such as sizes of things or indices into
> > > things. This is now causing some grief in
> > > https://ghc.haskell.org/trac/ghc/ticket/9416, where an allocation
> > boundary
> > > case test fails with a segfault because a n < m Int comparison overflows.
> > >
> > > I tried to fix the issue by changing the type of maxInlineAllocSize,
> > which
> > > is used on one side of the above comparison, to Word. However, that
> > > unravels a bunch of other issues, such as wordsToBytes, ByteOff, etc are
> > > all Int-valued quantities.
> > >
> > > I could perhaps work around these problems by judicious use of
> > fromIntegral
> > > in StgCmmPrim, but I'm a bit unhappy about it because it 1) makes the
> > code
> > > uglier and 2) needs to be done in quite a few places.
> > >
> > > How much work would it be to try to switch the codegen to use Word for
> > most
> > > of these quantities instead?
> > >
> > > -- Johan
> >
> >
> >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Improving the Int/Word story inside GHC

[Johan Tibell]

I'm hacking on this now. I'm not 100% sure that ByteOff isn't used for
negative values though, see for example

mkTaggedObjectLoad
  :: DynFlags -> LocalReg -> LocalReg -> ByteOff -> DynTag -> CmmAGraph
-- (loadTaggedObjectField reg base off tag) generates assignment
--  reg = bitsK[ base + off - tag ]
-- where K is fixed by 'reg'
mkTaggedObjectLoad dflags reg base offset tag
  = mkAssign (CmmLocal reg)
 (CmmLoad (cmmOffsetB dflags
  (CmmReg (CmmLocal base))
  (offset - tag))
  (localRegType reg))

from StgCmmUtils.

Wouldn't it be possible that the offset in cmmOffsetB (which is of type
ByteOff) could be negative?



On Thu, Aug 7, 2014 at 1:49 PM, Simon Peyton Jones 
wrote:

>  I’m all for it!
>
>
>
> I believe that ByteOff/WordOff are always 0 or positive.   At least, they
> were when I introduced them!
>
>
>
> SImon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-boun...@haskell.org] *On Behalf Of *Johan
> Tibell
> *Sent:* 07 August 2014 12:21
> *To:* Simon Marlow
> *Cc:* ghc-devs@haskell.org
> *Subject:* Re: Improving the Int/Word story inside GHC
>
>
>
> Simon M, is the intention of ByteOff and WordOff that they should be able
> to represent negative quantities as well? If so we might need to split it
> into ByteOff (still an Int) and ByteIndex (a Word) to have a type for
> indexing into arrays.
>
>
>
> On Thu, Aug 7, 2014 at 1:16 PM, Edward Z. Yang  wrote:
>
>  If it's strictly just in the codegen (and not affecting user code),
> seems fine to me.
>
> Edward
>
> Excerpts from Johan Tibell's message of 2014-08-07 12:10:37 +0100:
>
> > Inside GHC we mostly use Int instead of Word, even when we want to
> > represent non-negative values, such as sizes of things or indices into
> > things. This is now causing some grief in
> > https://ghc.haskell.org/trac/ghc/ticket/9416, where an allocation
> boundary
> > case test fails with a segfault because a n < m Int comparison overflows.
> >
> > I tried to fix the issue by changing the type of maxInlineAllocSize,
> which
> > is used on one side of the above comparison, to Word. However, that
> > unravels a bunch of other issues, such as wordsToBytes, ByteOff, etc are
> > all Int-valued quantities.
> >
> > I could perhaps work around these problems by judicious use of
> fromIntegral
> > in StgCmmPrim, but I'm a bit unhappy about it because it 1) makes the
> code
> > uglier and 2) needs to be done in quite a few places.
> >
> > How much work would it be to try to switch the codegen to use Word for
> most
> > of these quantities instead?
> >
> > -- Johan
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Improving the Int/Word story inside GHC

[Simon Peyton Jones]

I’m all for it!

I believe that ByteOff/WordOff are always 0 or positive.   At least, they were 
when I introduced them!

SImon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Johan Tibell
Sent: 07 August 2014 12:21
To: Simon Marlow
Cc: ghc-devs@haskell.org
Subject: Re: Improving the Int/Word story inside GHC

Simon M, is the intention of ByteOff and WordOff that they should be able to 
represent negative quantities as well? If so we might need to split it into 
ByteOff (still an Int) and ByteIndex (a Word) to have a type for indexing into 
arrays.

On Thu, Aug 7, 2014 at 1:16 PM, Edward Z. Yang 
mailto:ezy...@mit.edu>> wrote:
If it's strictly just in the codegen (and not affecting user code),
seems fine to me.

Edward

Excerpts from Johan Tibell's message of 2014-08-07 12:10:37 +0100:
> Inside GHC we mostly use Int instead of Word, even when we want to
> represent non-negative values, such as sizes of things or indices into
> things. This is now causing some grief in
> https://ghc.haskell.org/trac/ghc/ticket/9416, where an allocation boundary
> case test fails with a segfault because a n < m Int comparison overflows.
>
> I tried to fix the issue by changing the type of maxInlineAllocSize, which
> is used on one side of the above comparison, to Word. However, that
> unravels a bunch of other issues, such as wordsToBytes, ByteOff, etc are
> all Int-valued quantities.
>
> I could perhaps work around these problems by judicious use of fromIntegral
> in StgCmmPrim, but I'm a bit unhappy about it because it 1) makes the code
> uglier and 2) needs to be done in quite a few places.
>
> How much work would it be to try to switch the codegen to use Word for most
> of these quantities instead?
>
> -- Johan

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Improving the Int/Word story inside GHC

[Johan Tibell]

Simon M, is the intention of ByteOff and WordOff that they should be able
to represent negative quantities as well? If so we might need to split it
into ByteOff (still an Int) and ByteIndex (a Word) to have a type for
indexing into arrays.


On Thu, Aug 7, 2014 at 1:16 PM, Edward Z. Yang  wrote:

> If it's strictly just in the codegen (and not affecting user code),
> seems fine to me.
>
> Edward
>
> Excerpts from Johan Tibell's message of 2014-08-07 12:10:37 +0100:
> > Inside GHC we mostly use Int instead of Word, even when we want to
> > represent non-negative values, such as sizes of things or indices into
> > things. This is now causing some grief in
> > https://ghc.haskell.org/trac/ghc/ticket/9416, where an allocation
> boundary
> > case test fails with a segfault because a n < m Int comparison overflows.
> >
> > I tried to fix the issue by changing the type of maxInlineAllocSize,
> which
> > is used on one side of the above comparison, to Word. However, that
> > unravels a bunch of other issues, such as wordsToBytes, ByteOff, etc are
> > all Int-valued quantities.
> >
> > I could perhaps work around these problems by judicious use of
> fromIntegral
> > in StgCmmPrim, but I'm a bit unhappy about it because it 1) makes the
> code
> > uglier and 2) needs to be done in quite a few places.
> >
> > How much work would it be to try to switch the codegen to use Word for
> most
> > of these quantities instead?
> >
> > -- Johan
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Improving the Int/Word story inside GHC

[Edward Z . Yang]

If it's strictly just in the codegen (and not affecting user code),
seems fine to me.

Edward

Excerpts from Johan Tibell's message of 2014-08-07 12:10:37 +0100:
> Inside GHC we mostly use Int instead of Word, even when we want to
> represent non-negative values, such as sizes of things or indices into
> things. This is now causing some grief in
> https://ghc.haskell.org/trac/ghc/ticket/9416, where an allocation boundary
> case test fails with a segfault because a n < m Int comparison overflows.
> 
> I tried to fix the issue by changing the type of maxInlineAllocSize, which
> is used on one side of the above comparison, to Word. However, that
> unravels a bunch of other issues, such as wordsToBytes, ByteOff, etc are
> all Int-valued quantities.
> 
> I could perhaps work around these problems by judicious use of fromIntegral
> in StgCmmPrim, but I'm a bit unhappy about it because it 1) makes the code
> uglier and 2) needs to be done in quite a few places.
> 
> How much work would it be to try to switch the codegen to use Word for most
> of these quantities instead?
> 
> -- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Improving the Int/Word story inside GHC

[Johan Tibell]

Inside GHC we mostly use Int instead of Word, even when we want to
represent non-negative values, such as sizes of things or indices into
things. This is now causing some grief in
https://ghc.haskell.org/trac/ghc/ticket/9416, where an allocation boundary
case test fails with a segfault because a n < m Int comparison overflows.

I tried to fix the issue by changing the type of maxInlineAllocSize, which
is used on one side of the above comparison, to Word. However, that
unravels a bunch of other issues, such as wordsToBytes, ByteOff, etc are
all Int-valued quantities.

I could perhaps work around these problems by judicious use of fromIntegral
in StgCmmPrim, but I'm a bit unhappy about it because it 1) makes the code
uglier and 2) needs to be done in quite a few places.

How much work would it be to try to switch the codegen to use Word for most
of these quantities instead?

-- Johan
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: linker_unload validate related issue (how to duplicate that?).

[Karel Gardas]

Hi Edward,

thanks for dealing with this. I've found a little bit different reason. 
validate runs with ghc installed in bindisttest/install   dir/ and the 
tests invokes ghc-pkg to get gmp library path. The dir above is then 
returned quoted: "./install   dir/".
What I did in my linker_unload fix is to cut -d ' ' -f 1-1 IIRC which 
returned "/install and nothing more (quotes missing). The shell then 
complains with the message below.


Anyway, this is already fixed by reverting the patch and I already 
validated and pushed another version of it which correctly use head -1 
to get the intended first directory name...


Hopefully this time I've not broken anything.

Thanks!
Karel

On 08/ 6/14 12:04 PM, Edward Z. Yang wrote:

Austin and I chatted about it, and it's probably because the test is not
creating ghcconfig.h early enough.  I haven't looked further on how to
fix it though.

Edward

Excerpts from Karel Gardas's message of 2014-08-06 10:16:20 +0100:


Folks,

I've noted that validate is failing on Linux recently due to issue in
linker_unload. As I've submitted some patch to this test case recently
which fixes this on Solaris I'm kind of curious if I broke it or not.
Anyway, strange thing is: when I configure ghc and run the test by
(g)make TEST=linker_unload on both Linux and Solaris I get no failure.
When I validate on Linux (validate is not working on Solaris yet), then
I get failure in linker_unload:

Wrong exit code (expected 0 , actual 2 )
Stdout:

Stderr:
/bin/sh: 1: Syntax error: Unterminated quoted string
make[3]: *** [linker_unload] Error 2

*** unexpected failure for linker_unload(normal)


when I try to run:

cd testsuite
make TEST=linker_unload

inside this validation tree I again get no failure in this test:

[...]
=>  linker_unload(normal) 2522 of 4082 [0, 0, 0]
cd ./rts&&  $MAKE -s --no-print-directory linker_unloadlinker_unload.run.stdout 2>linker_unload.run.stderr

OVERALL SUMMARY for test run started at Wed Aug  6 10:55:17 2014 CEST
   0:00:08 spent to go through
  4082 total tests, which gave rise to
 13459 test cases, of which
 13458 were skipped

 0 had missing libraries
 1 expected passes
 0 expected failures

 0 caused framework failures
 0 unexpected passes
 0 unexpected failures

make[1]: Leaving directory `/home/karel/src/validate-test/testsuite/tests'

I've also noted that this test case fails on Solaris builders with
strange error:

=>  linker_unload(normal) 170 of 4082 [0, 0, 1]
cd ./rts&&  $MAKE -s --no-print-directory linker_unloadlinker_unload.run.stdout 2>linker_unload.run.stderr
Wrong exit code (expected 0 , actual 2 )
Stdout:
Stderr:
linker_unload: internal error: loadObj: can't read
`/buildbot/gabor-ghc-head-builder/builder/tempbuild/build/bindisttest/install/libHSinteg_BcPVjqcazPNGsNFG4agFty.a'
(GHC version 7.9.20140806 for i386_unknown_solaris2)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
gmake[3]: *** [linker_unload] Abort (core dumped)


So the question is: why validate fails and why builder fails on this
particular test and why my common testing on both Solaris and Linux is
not able to duplicate the issue? What's so different between validate
and builders and between my common: perl boot; ./configure; gmake -j12; cd testsuite; gmake THREADS=12 fast
?

Thanks!
Karel




___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs