Hi all, I have now pushed this change - there is a new type exposed from GHC.Types, in ghc-prim which is (unsurprisingly) named 'SPEC'. The SpecConstr pass will now explicitly look for both this type occurring as an argument, OR for a type which has ForceSpecConstr as an annotation.
This means it should now be possible to cross-compile vector with the stage1 compiler, once I submit a patch upstream. I will also add some more documentation shortly. On Thu, Oct 10, 2013 at 8:01 PM, Austin Seipp <[email protected]> wrote: > 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 > <[email protected]> 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 <[email protected]>: >> >>> It's also used by vector, which is widely deployed and, I think, doesn't >>> use TH otherwise. >>> >>> Manuel >>> >>> >>> Simon Peyton-Jones <[email protected]>: >>>> 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:[email protected]] On Behalf Of Manuel >>>> | M T Chakravarty >>>> | Sent: 10 October 2013 04:03 >>>> | To: Austin Seipp >>>> | Cc: Roman Leshchinskiy; [email protected] >>>> | 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 <[email protected]>: >>>> | > 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 >>>> | > [email protected] >>>> | > http://www.haskell.org/mailman/listinfo/ghc-devs >>>> | >>>> | _______________________________________________ >>>> | ghc-devs mailing list >>>> | [email protected] >>>> | http://www.haskell.org/mailman/listinfo/ghc-devs >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> [email protected] >>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> [email protected] >>> http://www.haskell.org/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> [email protected] >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > > -- > Regards, > > Austin Seipp, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
