Re: Vector registers assumed to be caller or callee-saved?
It is my understanding that we only communicate the calling convention to be used via LLVM IR and LLVM handles generation of the save/restore instructions required for the call. So indeed neither the macro nor this function would be used there. But I gathered that just by skimming the LLVM code at times so maybe I got something wrong there. Stefan Schulze Frielinghaus schrieb am 30.06.2019 um 20:36: But this only includes the NCG. What about the LLVM backend? For LLVM I only found in compiler/llvmGen/LlvmCodeGen/CodeGen.hs function definition getTrashRegs which makes use of function callerSaves which is defined in includes/CodeGen.Platform.hs: callerSaves :: GlobalReg -> Bool #if defined(CALLER_SAVES_Base) callerSaves BaseReg = True #endif ... callerSaves _ = False There only for general-purpose and floating-point registers function callerSaves may be defined to True. Thus, for XMMi, YMMi, and ZMMi arguments the function evaluates to False. Do I miss something for the LLVM backend? Maybe we just need to extend the definition of callerSaves in order to respect vector registers, too? Cheers, Stefan On Sun, Jun 30, 2019 at 07:16:15PM +0200, Andreas Klebinger wrote: What you want is not the macro but this function: https://hackage.haskell.org/package/ghc-8.6.5/docs/src/X86.Regs.html#callClobberedRegs whose results depend on the System ABI. Cheers, Andreas Hi all, I'm wondering what GHC assumes about vector registers XMMi, YMMi, and ZMMi used by the STG machine: are those assumed to be caller or callee-saved? Only for the x86-64 architecture there exist macro definitions like CALLER_SAVES_XMM1 in includes/stg/MachRegs.h. However, I cannot find any other place where those macros are used. AFAIK most C ABIs assume that vector registers are call clobbered. Is this also the case for GHC? Many thanks in advance, Stefan ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Vector registers assumed to be caller or callee-saved?
But this only includes the NCG. What about the LLVM backend? For LLVM I only found in compiler/llvmGen/LlvmCodeGen/CodeGen.hs function definition getTrashRegs which makes use of function callerSaves which is defined in includes/CodeGen.Platform.hs: callerSaves :: GlobalReg -> Bool #if defined(CALLER_SAVES_Base) callerSaves BaseReg = True #endif ... callerSaves _ = False There only for general-purpose and floating-point registers function callerSaves may be defined to True. Thus, for XMMi, YMMi, and ZMMi arguments the function evaluates to False. Do I miss something for the LLVM backend? Maybe we just need to extend the definition of callerSaves in order to respect vector registers, too? Cheers, Stefan On Sun, Jun 30, 2019 at 07:16:15PM +0200, Andreas Klebinger wrote: > What you want is not the macro but this function: > https://hackage.haskell.org/package/ghc-8.6.5/docs/src/X86.Regs.html#callClobberedRegs > > > whose results depend on the System ABI. > > Cheers, > Andreas > > > > > > Hi all, > > > > I'm wondering what GHC assumes about vector registers XMMi, YMMi, and ZMMi > > used > > by the STG machine: are those assumed to be caller or callee-saved? Only for > > the x86-64 architecture there exist macro definitions like > > CALLER_SAVES_XMM1 in > > includes/stg/MachRegs.h. However, I cannot find any other place where those > > macros are used. AFAIK most C ABIs assume that vector registers are call > > clobbered. Is this also the case for GHC? > > > > Many thanks in advance, > > Stefan > > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Vector registers assumed to be caller or callee-saved?
What you want is not the macro but this function: https://hackage.haskell.org/package/ghc-8.6.5/docs/src/X86.Regs.html#callClobberedRegs whose results depend on the System ABI. Cheers, Andreas Hi all, I'm wondering what GHC assumes about vector registers XMMi, YMMi, and ZMMi used by the STG machine: are those assumed to be caller or callee-saved? Only for the x86-64 architecture there exist macro definitions like CALLER_SAVES_XMM1 in includes/stg/MachRegs.h. However, I cannot find any other place where those macros are used. AFAIK most C ABIs assume that vector registers are call clobbered. Is this also the case for GHC? Many thanks in advance, Stefan ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Workflow question (changing codegen)
Re: git worktree: That's the workflow I'm currently using. It has its problems with submodules, see https://stackoverflow.com/questions/31871888/what-goes-wrong-when-using-git-worktree-with-git-submodules. But you can make it work with this git alias from the first answer: https://gitlab.com/clacke/gists/blob/0c4a0b6e10f7fbf15127339750a6ff490d9aa3c8/.config/git/config#L12. Just go into your main checkout and do `git wtas ../T9876`. AFAIR it interacts weirdly with MinGW's git or git for Windows, but nothing you can't work around. Anyway, I was hoping that one day hadrian will be smart enough to have a build directory for each branch or something, so that I would only need one checkout where I can switch between branches as needed. In the meantime, `git wtas` does what I want. Am Sa., 29. Juni 2019 um 21:53 Uhr schrieb Richard Eisenberg < r...@richarde.dev>: > Just to pass on something that looks cool (I haven't tried it myself yet): > git worktree. It seems git can hang several different checkouts of a repo > in different directories. This seems far superior to my current habit of > having many clones of ghc, sometimes going through machinations to get > commits from one place to another. The documentation for git worktree seems > quite approachable, so you might find it useful. I plan on using it in the > future. > > Richard > > > On Jun 29, 2019, at 8:24 AM, Ben Gamari wrote: > > > > On June 28, 2019 5:09:45 AM EDT, "Ömer Sinan Ağacan" < > omeraga...@gmail.com> wrote: > >> Hi all, > >> > >> I'm currently going through this torturous process and I'm hoping that > >> someone > >> here will be able to help. > >> > >> I'm making changes in the codegen. My changes are currently buggy, and > >> I need a > >> working stage 1 compiler to be able to debug. Basically I need to build > >> libraries using the branch my changes are based on, then build stage 1 > >> with my > >> branch, so that I'll be able to build and run programs using stage 1 > >> that uses > >> my codegen changes. The changes are compatible with the old codegen > >> (i.e. no > >> changes in calling conventions or anything like that) so this should > >> work. > >> > >> Normally I do this > >> > >> $ git checkout master > >> $ git distclean && ./boot && ./configure && make > >> $ git checkout my_branch > >> $ cd compiler; make 1 > >> > >> This gives me stage 1 compiler that uses my buggy codegen changes, plus > >> libraries built with the old and correct codegen. > >> > >> However the problem is I'm also adding a new file in my_branch, and the > >> build > >> system just doesn't register that fact, even after adding the line I > >> added to > >> compiler/ghc.cabal.in to compiler/ghc.cabal. So far the only way to fix > >> this > >> that I could find was to run ./configure again, then run make for a few > >> seconds > >> at the top level, then do `make 1` in compiler/. Unfortunately even > >> that doesn't > >> work when the master branch and my_branch have different dates, because > >> `make` > >> in master branch produces a different version than the `make` in > >> my_branch, so > >> the interface files become incompatible. > >> > >> Anyone have any ideas on how to proceed here? > >> > >> Thanks, > >> > >> Ömer > >> ___ > >> ghc-devs mailing list > >> ghc-devs@haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > In general I think it is wise to avoid switching branches in a tree you > are actively developing in. The cost of switching both in the compilation > time that it implies and the uncertain state that it leaves the tree in is > in my opinion too high. It you want to compare your change against master I > would recommend using two working directories. > > > > > > 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 > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
