Turning ForceSpecConstr/NoSpecConstr into pragmas?

Fri Oct 11 01:01:27 UTC 2013

Yes, I agree, but it's quite a bit of work to do this. I believe the
plan of attack laid out at one point was: compile both for the host,
and the target. Then, the cross-stage2 compiler when needing e.g. to
load template haskell code, can load copies of the *host* libraries
instead into the GHC process, and use them to emit code for the final
binary, for the target platform.

Unfortunately the naive approach to this would fall on its face in
some cases I think - consider cross compiling x86_64 -> ARMv7 --
`sizeOf (undefined :: Ptr a)` will be different across the two, so
loading the host libraries would imply a pointer size of 8 bytes,
while the target actually has a pointer size of 4 bytes. If you used
Template Haskell to generate code on this example (for example
emitting the ptr size into the resulting binary as a literal integer)
then it'll actually be subtly wrong.

On Thu, Oct 10, 2013 at 6:25 PM, Manuel M T Chakravarty
<chak at cse.unsw.edu.au> wrote:
> [First attempt sent from wrong account.]
>
> The real solution, in the general scheme of things, would be to make TH work with cross-compilation. I think, the ghc-iOS folks do have a concrete plan for that (i.e., a cross-compiler needs to generate two binaries, one for the target arch and one for the host arch).
>
> Manuel
>
> Manuel M T Chakravarty <chak at cse.unsw.edu.au>:
>
>> It's also used by vector, which is widely deployed and, I think, doesn't use TH otherwise.
>>
>> Manuel
>>
>>
>> Simon Peyton-Jones <simonpj at microsoft.com>:
>>> It's true that I suggested making it an annotation.  The DPH libraries use a lot of Template Haskell and so have to be compiled with a stage2 compiler anyway.
>>>
>>> The thing about ForceSpecConstr is that it is an unprincipled hack that I hate with a passion. It clearly is not the Right Thing. I just don't yet know a better way to do it.  Johan suggests a more principled approach, about eliminating uses of the stream constructor. I know that Roman considered that but could not make it work.  I'm afraid I can't remember why.
>>>
>>> Because it is such a hack I'm reluctant to bake it more deeply into the compiler, and to sink further effort into doing so.  Also I'm not sure what problem we are trying to solve here. If it's compiling DPH libraries with stage1, that won't work because they use TH.
>>>
>>> All that said, I don't seriously object to someone making it a pragma if you want.   Just make clear that it's a horrible hack.
>>>
>>> Simon
>>>
>>>
>>> | -----Original Message-----
>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Manuel
>>> | M T Chakravarty
>>> | Sent: 10 October 2013 04:03
>>> | To: Austin Seipp
>>> | Cc: Roman Leshchinskiy; ghc-devs at haskell.org
>>> | Subject: Re: Turning ForceSpecConstr/NoSpecConstr into pragmas?
>>> |
>>> | This feature was implemented as an annotation by Roman in part because
>>> | Simon was keen to see the then new annotation feature used, in part
>>> | because we were unsure whether the design would last, and it part as it
>>> | seemed easier than hacking it into GHC.
>>> |
>>> | Personally, I would have always preferred it to be a proper pragma,
>>> | mainly for the reason that causes grief now (i.e., because it requires
>>> | stage2). So, as far as I'm concerned, please make it a pragma.
>>> |
>>> | Manuel
>>> |
>>> | Austin Seipp <austin at well-typed.com>:
>>> | > Hello all,
>>> | >
>>> | > Early last week I was reminded of something, which was that vector/dph
>>> | > depend on the stage2 compiler - this is because both packages use
>>> | > annotations to specify ForceSpecConstr and NoSpecConstr on several key
>>> | > datatypes.
>>> | >
>>> | > For most of our platforms (now including ARM,) this should generally
>>> | > be OK, because we have stage2 and the linker available to support it.
>>> | >
>>> | > But in particular, it makes vector and dph unusable for cross
>>> | > compilers. This might be somewhat problematic for e.g. iOS or an RPi,
>>> | > where we only have a stage1 cross compiler - but it's reasonable to
>>> | > assume we may want to use vector there! And more and more libraries
>>> | > depend on vector these days.
>>> | >
>>> | > I believe these are the only instances in which vector/dph needs
>>> | > stage2. So I ask: is it reasonable to change this to a pragma built
>>> | > into the compiler? That is,
>>> | >
>>> | > ------------------------------------------------------------
>>> | > data SPEC = SPEC | SPEC2
>>> | > {-# ANN type SPEC ForceSpecConstr #-}
>>> | >
>>> | > data PArray a
>>> | >        = PArray Int# (PData  a)
>>> | > {-# ANN type PArray NoSpecConstr #-}
>>> | > -------------------------------------------------------------
>>> | >
>>> | > becomes something like:
>>> | >
>>> | > -------------------------------------------------------------
>>> | > data SPEC = SPEC | SPEC2
>>> | > {-# SPECIALIZE Constructor SPEC #-}
>>> | >
>>> | > data PArray a
>>> | >        = PArray Int# (PData  a)
>>> | > {-# NOSPECIALIZE Constructor PArray #-}
>>> | > -------------------------------------------------------------
>>> | >
>>> | > I'm not particularly interested in a bikeshedding discussion about the
>>> | > exact syntax for the pragma (although this somewhat falls in line with
>>> | > 'INLINE ConLike' as a special case,) - I just want to know if this
>>> | > sounds reasonable.
>>> | >
>>> | > Looking at SpecConstr in the compiler, there seems to be quite a lot
>>> | > of note summarising that we need a better design - in particular,
>>> | > notes about nuking NoSpecConstr (as it appeared before
>>> | > ForceSpecConstr,) and turning ForceSpecConstr into a library type of
>>> | > some sort. I don't propose changing any of this really, just removing
>>> | > the dependency on the annotations.
>>> | >
>>> | > But if someone thinks a library type would be better suited for this -
>>> | > I'm totally fine with that too and am all-ears for a suggestion.
>>> | >
>>> | > And of course, both of these can continue to be supported for a while,
>>> | > although the patches to vector, at least, would be trivial to switch
>>> | > it over.
>>> | >
>>> | > Ben, Manuel, Simon - you three are the experts here I believe.
>>> | > Thoughts? Perhaps I'm missing something key here?
>>> | >
>>> | > --
>>> | > Regards,
>>> | >
>>> | > Austin Seipp, Haskell Consultant
>>> | > Well-Typed LLP, http://www.well-typed.com/
>>> | > _______________________________________________
>>> | > ghc-devs mailing list
>>> | > ghc-devs at haskell.org
>>> | > http://www.haskell.org/mailman/listinfo/ghc-devs
>>> |
>>> | _______________________________________________
>>> | ghc-devs mailing list
>>> | ghc-devs at haskell.org
>>> | http://www.haskell.org/mailman/listinfo/ghc-devs
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/