Re: 8-bit and 16-bit arithmetic
yeah, like, currently the XOR for setting registers to zero trick / code optimization (first implemented in ghc backend by reid barton) is done as part of the pretty printer on X86/AMD_64 targets this and a lot of other easy win peephole optimizations that are platform /target dependent happen in the pretty printer atm I thnk On Thu, Oct 28, 2021 at 5:38 PM Ben Gamari wrote: > Norman Ramsey writes: > > > On x86, GHC can translate 8-bit and 16-bit operations directly > > into the 8-bit and 16-bit machine instructions that the hardware > > supports. But there are other platforms on which the smallest > > unit of arithmetic may be 32 or even 64 bits. Is there a central > > module in GHC that can take care of rewriting 8-bit and 16-bit operations > > into 32-bit or 64-bit operations? Or is each back end on its own > > for this? > > > > (One of my students did some nice work on implementing this > transformation > > with a minimal set of sign-extension and zero-extension operations: > > https://www.cs.tufts.edu/~nr/pubs/widen.pdf.) > > > As Carter indicated, this is currently done on a per-backend basis. This > could indeed probably be consolidated, although we would want to make > sure that in so doing we do not leave easy money on the table: It seems > plausible to me that the backend may be able to generate better code > than a naive lowering to wide arithmetic might otherwise generate. > > Cheers, > > - Ben > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: 8-bit and 16-bit arithmetic
Norman Ramsey writes: > On x86, GHC can translate 8-bit and 16-bit operations directly > into the 8-bit and 16-bit machine instructions that the hardware > supports. But there are other platforms on which the smallest > unit of arithmetic may be 32 or even 64 bits. Is there a central > module in GHC that can take care of rewriting 8-bit and 16-bit operations > into 32-bit or 64-bit operations? Or is each back end on its own > for this? > > (One of my students did some nice work on implementing this transformation > with a minimal set of sign-extension and zero-extension operations: > https://www.cs.tufts.edu/~nr/pubs/widen.pdf.) > As Carter indicated, this is currently done on a per-backend basis. This could indeed probably be consolidated, although we would want to make sure that in so doing we do not leave easy money on the table: It seems plausible to me that the backend may be able to generate better code than a naive lowering to wide arithmetic might otherwise generate. Cheers, - Ben signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: 8-bit and 16-bit arithmetic
I think carter has it still right that it happens in the backends. If a new backend doesn't support these we could move this up into Cmm though without much issue I think. Am 28/10/2021 um 23:12 schrieb Carter Schonwald: I think thats done on a per backend basis (though theres been a lot of changes since i last looked at some of the relevent pieces). (i'm actually based in Cambridge MA for the next 1-2 years if you wanna brain storm IRL sometime) On Thu, Oct 28, 2021 at 4:59 PM Norman Ramsey wrote: On x86, GHC can translate 8-bit and 16-bit operations directly into the 8-bit and 16-bit machine instructions that the hardware supports. But there are other platforms on which the smallest unit of arithmetic may be 32 or even 64 bits. Is there a central module in GHC that can take care of rewriting 8-bit and 16-bit operations into 32-bit or 64-bit operations? Or is each back end on its own for this? (One of my students did some nice work on implementing this transformation with a minimal set of sign-extension and zero-extension operations: https://www.cs.tufts.edu/~nr/pubs/widen.pdf.) Norman ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Exact Print Annotations : Anchor in a SrcSpan
I have been updating the ghc-exactprint library for real world use cases on the about to be released GHC 9.2.1, and realised I need to be able to put an Anchor into every SrcSpan in the ParsedSource AST. I prepared !6854 to sort it out in master and turned to the problem of GHC 9.2.1, where I had missed the boat. And then I discovered that we have SrcSpan defined as data SrcSpan = RealSrcSpan !RealSrcSpan !(Maybe BufSpan) | UnhelpfulSpan !UnhelpfulSpanReason and the (Maybe BufSpan) is only used for attaching haddock comments after parsing. This means there is an isomorphism between the RealSrcSpan variant and an Anchor, which I take advantage of with the code in [1], by using the Maybe to encode the AnchorOperation and the BufSpan to encode the DeltaPos. And it struck me that perhaps we should make this a more official approach. The only problem is the detail of the BufSpan, to be able to play both roles cleanly. Alan [1] https://gist.github.com/alanz/5e262599ab79138606cdfcf3792ef635 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: 8-bit and 16-bit arithmetic
I think thats done on a per backend basis (though theres been a lot of changes since i last looked at some of the relevent pieces). (i'm actually based in Cambridge MA for the next 1-2 years if you wanna brain storm IRL sometime) On Thu, Oct 28, 2021 at 4:59 PM Norman Ramsey wrote: > On x86, GHC can translate 8-bit and 16-bit operations directly > into the 8-bit and 16-bit machine instructions that the hardware > supports. But there are other platforms on which the smallest > unit of arithmetic may be 32 or even 64 bits. Is there a central > module in GHC that can take care of rewriting 8-bit and 16-bit operations > into 32-bit or 64-bit operations? Or is each back end on its own > for this? > > (One of my students did some nice work on implementing this transformation > with a minimal set of sign-extension and zero-extension operations: > https://www.cs.tufts.edu/~nr/pubs/widen.pdf.) > > > Norman > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
8-bit and 16-bit arithmetic
On x86, GHC can translate 8-bit and 16-bit operations directly into the 8-bit and 16-bit machine instructions that the hardware supports. But there are other platforms on which the smallest unit of arithmetic may be 32 or even 64 bits. Is there a central module in GHC that can take care of rewriting 8-bit and 16-bit operations into 32-bit or 64-bit operations? Or is each back end on its own for this? (One of my students did some nice work on implementing this transformation with a minimal set of sign-extension and zero-extension operations: https://www.cs.tufts.edu/~nr/pubs/widen.pdf.) Norman ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Running GHC in GHCi
Looks good Ben. Would it be good to add a target to hadrian which builds just the right dependencies for this to work? and then deals with setting options such as -B as well. Matt On Thu, Oct 28, 2021 at 5:26 AM Bryan Richter wrote: > > That's very exciting! > > On Thu, 28 Oct 2021, 3.08 Ben Gamari, wrote: >> >> Ben Gamari writes: >> >> > Hi all, >> > >> > Today I verified that with Luite's recent work on the interpreter it is >> > now possible to run GHC entirely within GHCi (when bootstrapping from >> > GHC 9.2). >> > >> > ... >> > >> I have fixed the break-array issue noted in the above message in !6848. >> It is now possible to use `:trace` on GHC itself: >> >> >> $ hadrian/ghci >> GHCi, version 9.2.1: https://www.haskell.org/ghc/ :? for help >> . >> . >> . >> λ> import Main >> λ> :set args -B/opt/exp/ghc/ghc-landing/_build/stage1/lib Hi.hs -v3 >> -fforce-recomp >> λ> :set -fbreak-on-error >> λ> :trace main >> Glasgow Haskell Compiler, Version 9.3.20211027, stage 1 booted by GHC >> version 9.2.1 >> ^CStopped in , >> _exception :: e = _ >> [] λ> :hist >> -1 : fromException >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Utils/Panic.hs:114:19-24) >> -2 : uniq >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:205:7-10) >> -3 : moduleNameFS >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:72:33-35) >> -4 : stableModuleNameCmp >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:62:64-78) >> -5 : lexicalCompareFS >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:252:18-25) >> -6 : uniq >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:205:7-10) >> -7 : moduleNameFS >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:72:33-35) >> -8 : stableModuleNameCmp >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:62:29-43) >> -9 : lexicalCompareFS >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:252:6-13) >> -10 : lexicalCompareFS >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:252:6-25) >> -11 : lexicalCompareFS >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:(252,3)-(253,54)) >> -12 : stableModuleNameCmp >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:62:29-78) >> -13 : compare >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:42:23-49) >> -14 : fs_sbs >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:207:7-12) >> -15 : lexicalCompareFS >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:253:44-53) >> -16 : fs_sbs >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:207:7-12) >> -17 : lexicalCompareFS >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:253:31-40) >> -18 : lexicalCompareFS >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:253:3-54) >> -19 : uniq >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:205:7-10) >> -20 : moduleNameFS >> (/opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:72:33-35) >> ... >> [] λ> :back >> Logged breakpoint at >> /opt/exp/ghc/ghc-landing/compiler/GHC/Utils/Panic.hs:114:19-24 >> _result :: Maybe GHC.Utils.Panic.Plain.PlainGhcException >> e :: SomeAsyncException >> [-1: /opt/exp/ghc/ghc-landing/compiler/GHC/Utils/Panic.hs:114:19-24] λ> :back >> Logged breakpoint at >> /opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:205:7-10 >> _result :: Int >> uniq :: Int >> [-2: /opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:205:7-10] λ> >> uniq >> 603980920 >> [-2: /opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:205:7-10] λ> >> :back >> Logged breakpoint at >> /opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:72:33-35 >> _result :: ModuleName >> mod :: ModuleName >> [-3: /opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:72:33-35] λ> >> mod >> ModuleName "GHC.Tc.Solver.Canonical" >> >> et cetera >> ___ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
