Re: ARM64 Task Force
I've pushed my WIP patches here: https://github.com/lukexi/llvm/commit/dfe74bb48eb05ce7847fa262f6e563d20d0b1fc5 https://github.com/lukexi/ghc/commit/e99b7a41e64f3ddb9bb420c0d5583f0e302e321e (they also require the latest libffi to be dropped in ftp://sourceware.org/pub/libffi/libffi-3.0.13.tar.gz due to https://ghc.haskell.org/trac/ghc/ticket/8664) These can produce an ARM64 GHC but the produced binaries aren't fully functional yet. They make it through hs_init() but crash rather opaquely when I try to call a simple fib function through the FFI. It looks like it's jumping somewhere strange; lldb tells me it's to 0x100e05110: .long 0x; unknown opcode 0x100e05114: .long 0x; unknown opcode 0x100e05118: .long 0x; unknown opcode 0x100e0511c: .long 0x; unknown opcode 0x100e05120: .long 0x; unknown opcode 0x100e05124: .long 0x; unknown opcode 0x100e05128: .long 0x; unknown opcode 0x100e0512c: .long 0x; unknown opcode If I put a breakpoint on StgRun and step by instruction, I seem to make it to about: https://github.com/lukexi/ghc/blob/e99b7a41e64f3ddb9bb420c0d5583f0e302e321e/rts/StgCRun.c#L770 (give or take a line) before something goes mysteriously wrong and I'm no longer able to interact with the debugger. So I guess I'll try taking out float register support and see if that gets me anywhere. If anyone has some ideas on how to debug this I'd love to hear them! I've mostly assembled the patches by adapting the existing ARM support so it's quite possibly I'm doing something boneheaded. Cheers Luke On Sun, Aug 10, 2014 at 6:44 PM, Luke Iannini lukex...@gmail.com wrote: I think I've solved this particular mystery -- the registers were never defined there because that integer-representation of them is only used by the NCG. In LLVM land they were only ever stringified by the REG() macro. Except now globalRegMaybe is being used in CmmSink.hs (as Simon and Ben were discussing), and globalRegMaybe needs an integer value for each register to put into its Maybe RealReg return value. Since CmmSink.hs only checks 'isJust', it doesn't actually matter what the integer value is. So I've just gone ahead and defined them sequentially for now which seems to get me past this. Thanks! Luke On Sat, Aug 9, 2014 at 4:22 AM, Karel Gardas karel.gar...@centrum.cz wrote: On 08/ 9/14 05:27 AM, Luke Iannini wrote: Hi Karel, Thanks! A question: https://git.haskell.org/ghc.git/commitdiff/ 454b34cb3b67dec21f023339c4d53d734af7605d adds references to s16, s17, s18, s19, d10 and d11 but I don't see those Yes, that adds FPU support for ARM. where I though to expect them in https://github.com/ghc/ghc/blob/master/includes/CodeGen.Platform.hs Hmm, whole ARM reg set is missing in this file. IIRC Simon Marlow were discussing this with Ben Gamari recently. I've not investigated if this is needed or not since I don't know if this is used only in NCG or in registerised build in general. If the former, ARM will not be there as there is no ARM NCG yet, if the later, then ARM should be there as ARM/LLVM/registerised build is a reality. Cheers, Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: ARM64 Task Force
On 08/12/14 11:03 AM, Luke Iannini wrote: It looks like it's jumping somewhere strange; lldb tells me it's to 0x100e05110: .long 0x ; unknown opcode 0x100e05114: .long 0x ; unknown opcode 0x100e05118: .long 0x ; unknown opcode 0x100e0511c: .long 0x ; unknown opcode 0x100e05120: .long 0x ; unknown opcode 0x100e05124: .long 0x ; unknown opcode 0x100e05128: .long 0x ; unknown opcode 0x100e0512c: .long 0x ; unknown opcode If I put a breakpoint on StgRun and step by instruction, I seem to make it to about: https://github.com/lukexi/ghc/blob/e99b7a41e64f3ddb9bb420c0d5583f0e302e321e/rts/StgCRun.c#L770 (give or take a line) strange that it's in the middle of the stp isns block. Anyway, this looks like a cpu exception doesn't it? You will need to find out the reg which holds the exception reason value and then look on it in your debugger to find out what's going wrong there. Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
making ./validate run tests on all CPUs by default
Good evening all! Currently when being ran './validate' script (without any parameters): - builds ghc using 2 parallel jobs - runs testsuite using 2 parallel jobs I propose to change the default value to amount of available CPUs: - build ghc using N+1 parallel jobs - run testsuite using N+1 parallel jobs Pros: - first-time users will get faster ./validate - seasoned users will need less tweaking for buildbots Cons: - for imbalanced boxes (32 cores, 8GB RAM) it might be quite painful to drag box out of swap What do you think about it? Actual patch: https://phabricator.haskell.org/D146 Thanks! -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Broken Data.Data instances
Status update I have worked through a proof of concept update to the GHC AST whereby the type is provided as a parameter to each data type. This was basically a mechanical process of changing type signatures, and required very little actual code changes, being only to initialise the placeholder types. The enabling types are type PostTcType = Type-- Used for slots in the abstract syntax -- where we want to keep slot for a type -- to be added by the type checker...but -- [before typechecking it's just bogus] type PreTcType = () -- used before typechecking class PlaceHolderType a where placeHolderType :: a instance PlaceHolderType PostTcType where placeHolderType = panic Evaluated the place holder for a PostTcType instance PlaceHolderType PreTcType where placeHolderType = () These are used to replace all instances of PostTcType in the hsSyn types. The change was applied against HEAD as of last friday, and can be found here https://github.com/alanz/ghc/tree/wip/landmine-param https://github.com/alanz/haddock/tree/wip/landmine-param They pass 'sh validate' with GHC 7.6.3, and compile against GHC 7.8.3. I have not tried to validate that yet, have no reason to expect failure. Can I please get some feedback as to whether this is a worthwhile change? It is the first step to getting a generic traversal safe AST Regards Alan On Mon, Jul 28, 2014 at 5:45 PM, Alan Kim Zimmerman alan.z...@gmail.com wrote: FYI I edited the paste at http://lpaste.net/108262 to show the problem On Mon, Jul 28, 2014 at 5:41 PM, Alan Kim Zimmerman alan.z...@gmail.com wrote: I already tried that, the syntax does not seem to allow it. I suspect some higher form of sorcery will be required, as alluded to here http://stackoverflow.com/questions/14133121/can-i-constrain-a-type-family Alan On Mon, Jul 28, 2014 at 4:55 PM, p.k.f.holzensp...@utwente.nl wrote: Dear Alan, I would think you would want to constrain the result, i.e. type family (Data (PostTcType a)) = PostTcType a where … The Data-instance of ‘a’ doesn’t give you much if you have a ‘PostTcType a’. Your point about SYB-recognition of WrongPhase is, of course, a good one ;) Regards, Philip *From:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com] *Sent:* maandag 28 juli 2014 14:10 *To:* Holzenspies, P.K.F. (EWI) *Cc:* Simon Peyton Jones; Edward Kmett; ghc-devs@haskell.org *Subject:* Re: Broken Data.Data instances Philip I think the main reason for the WrongPhase thing is to have something that explicitly has a Data and Typeable instance, to allow generic (SYB) traversal. If we can get by without this so much the better. On a related note, is there any way to constrain the 'a' in type family PostTcType a where PostTcType Id= TcType PostTcType other = WrongPhaseTyp to have an instance of Data? I am experimenting with traversals over my earlier paste, and got stuck here (which is the reason the Show instances were commentet out in the original). Alan On Mon, Jul 28, 2014 at 12:30 PM, p.k.f.holzensp...@utwente.nl wrote: Sorry about that… I’m having it out with my terminal server and the server seems to be winning. Here’s another go: I always read the () as “there’s nothing meaningful to stick in here, but I have to stick in something” so I don’t necessarily want the WrongPhase-thing. There is very old commentary stating it would be lovely if someone could expose the PostTcType as a parameter of the AST-types, but that there are so many types and constructors, that it’s a boring chore to do. Actually, I was hoping haRe would come up to speed to be able to do this. That being said, I think Simon’s idea to turn PostTcType into a type-family is a better way altogether; it also documents intent, i.e. () may not say so much, but PostTcType RdrName says quite a lot. Simon commented that a lot of the internal structures aren’t trees, but cyclic graphs, e.g. the TyCon for Maybe references the DataCons for Just and Nothing, which again refer to the TyCon for Maybe. I was wondering whether it would be possible to make stateful lenses for this. Of course, for specific cases, we could do this, but I wonder if it is also possible to have lenses remember the things they visited and not visit them twice. Any ideas on this, Edward? Regards, Philip *From:* Alan Kim Zimmerman [mailto:alan.z...@gmail.com] *Sent:* maandag 28 juli 2014 11:14 *To:* Simon Peyton Jones *Cc:* Edward Kmett; Holzenspies, P.K.F. (EWI); ghc-devs *Subject:* Re: Broken Data.Data instances I have made a conceptual example of this here http://lpaste.net/108262 Alan On Mon, Jul 28, 2014 at 9:50 AM, Alan Kim Zimmerman alan.z...@gmail.com wrote: What about creating a specific type with a single constructor for the not relevant to this phase type
Re: CPP usage in GHC.
Actually probably not debris leftover but needed code. I just removed -x assembler-with-cpp and got this: gcc: ghc/Main.hs: linker input file unused because linking not done so we definitely need some -x to set language even for GNU C. Tested also with old 3.4.x. From langs available, assembler-with-cpp looks like the best option unfortunately... Karel On 08/12/14 01:35 AM, Carter Schonwald wrote: Oo. Then it's possibly debris leftover from Austin's initial clang compatibility work predating the improvements via the settings file work. I'm Afk right now, but that probably can be safely removed from ghc, especially since the configure script for clang cpp adds that anyways now I think? I might be wrong though. On Monday, August 11, 2014, Karel Gardas karel.gar...@centrum.cz mailto:karel.gar...@centrum.cz wrote: On 08/11/14 11:18 PM, Carter Schonwald wrote: why should this flag be passed to cpp when invoked on HS files? It'd be easy to expose another field in the settings file for this other invokecation.. though i should look more closely at the use site before opinining :) Hmm, isn't doCpp function what's invoked when cpp is invoked for HS files? If so, then -x assembler-with-cpp is already used for HS files anyway. Karel On Mon, Aug 11, 2014 at 4:27 PM, Karel Gardas karel.gar...@centrum.cz mailto:karel.gar...@centrum.cz wrote: On 08/11/14 08:48 PM, Carter Schonwald wrote: What i'm hearing you say is we actually need TWO sets of CPP flags, one for normal haskell, and another for the CPP used on the assembler? wheres this hardcoding? DriverPipeline.hs -- grep for assembler-with-cpp and you will find it. IMHO best would be to move this -x assembler-with-cpp into the hs-cpp-flags managed by configure. This way it may be even possible to use system supplied plain cpp instead of cpp builtinto GNU C. Karel ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
