Is it possible to enhance the vector STG registers(Xmm, Ymm, Zmm) with more information?
Simon Peyton Jones
simonpj at microsoft.com
Fri Jul 13 22:22:36 UTC 2018
Typesetting is really strange here. Hard to read.
Yes, let’s get rid of those Maybes if poss. What does Nothing mean???
Does this mean that Xmm regs really can contain multiple integers or multiple floats? I did not know that.
the general direction looks right.
Thanks
Simon
From: Abhiroop Sarkar <asiamgenius at gmail.com>
Sent: 13 July 2018 16:32
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: ghc-devs at haskell.org
Subject: Re: Is it possible to enhance the vector STG registers(Xmm, Ymm, Zmm) with more information?
The formatting of the function[1] got spoilt in the last mail. It is modified from:
globalRegType _ (XmmReg _) = cmmVec 4 (cmmBits W32)
to
globalRegType _ (XmmReg _ m ty) = let (l,w) = fromMaybe (2, W64) m
in case fromMaybe Float ty of
Integer -> cmmVec l (cmmBits w)
Float -> cmmVec l (cmmFloat w)
Thank,
Abhiroop
[1] https://github.com/Abhiroop/ghc-1/blob/wip/simd-ncg-support/compiler/cmm/CmmExpr.hs#L596<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAbhiroop%2Fghc-1%2Fblob%2Fwip%2Fsimd-ncg-support%2Fcompiler%2Fcmm%2FCmmExpr.hs%23L596&data=02%7C01%7Csimonpj%40microsoft.com%7Cee2fb4d91cfc45ae307808d5e8d5d097%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636670927384427518&sdata=XngOwITn9xqGS417NO16ftCgC8%2BGa1NidVraLD7KS1I%3D&reserved=0>
On Fri, Jul 13, 2018 at 4:26 PM Abhiroop Sarkar <asiamgenius at gmail.com<mailto:asiamgenius at gmail.com>> wrote:
Sorry I mistyped and forgot to include the register number in the mail but it is present in the patch. So it is:
data GlobalReg = ...
| XmmReg !Int
(Maybe (Length, Width))
(Maybe GlobalVecRegTy)
The purpose of the GlobalVecRegTy field is to rewrite this function definition : https://github.com/ghc/ghc/blob/master/compiler/cmm/CmmExpr.hs#L585-L587<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc%2Fghc%2Fblob%2Fmaster%2Fcompiler%2Fcmm%2FCmmExpr.hs%23L585-L587&data=02%7C01%7Csimonpj%40microsoft.com%7Cee2fb4d91cfc45ae307808d5e8d5d097%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636670927384437535&sdata=50vVucmqx1KOIVJUMnqby1%2BxRkE2nv7CG5qbkDZ0g3c%3D&reserved=0>
globalRegType _ (XmmReg _) = cmmVec 4 (cmmBits W32)
and rewrite it to :
globalRegType _ (XmmReg _ m ty) = let (l,w) = fromMaybe (2, W64) m -- a random default value of 2 and W64 chosen in case fromMaybe Float ty of Integer -> cmmVec l (cmmBits w) Float -> cmmVec l (cmmFloat w) Thanks, Abhiroop
On Fri, Jul 13, 2018 at 4:12 PM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
What is the GlobalVecRegTy field doing?
Don’t you need an Int for the register number, like all the rest?
Generally, sounds good though
S
From: Abhiroop Sarkar <asiamgenius at gmail.com<mailto:asiamgenius at gmail.com>>
Sent: 13 July 2018 14:07
To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Cc: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Re: Is it possible to enhance the vector STG registers(Xmm, Ymm, Zmm) with more information?
Hello Simon,
Thanks for your response. I had written a patch[1] for this and the approach I took was quite similar to what you pointed out.
data GlobalReg = ...
| XmmReg
(Maybe (Length, Width))
(Maybe GlobalVecRegTy)
data GlobalVecRegTy = Integer | Float
-- Width and Length are already defined
data Width = W8 | W16 | W32 .....
type Length = Int
I wrapped the types inside a `Maybe` because when initializing a GlobalReg (in the `activeStgRegs`[2] function), I was not sure what value to initialize the register with, so I used a `Nothing` when initializing.
I see now in the case of `VanillaReg` it is initialized with the `VGcPtr` constructor: VanillaReg 1 VGcPtr etc
I think I should modify my patch as well to remove the Maybe and initialize with some default Length, Width and GlobalRegTy. Thanks for the help.
Abhiroop
[1] https://phabricator.haskell.org/D4922
[2] https://github.com/ghc/ghc/blob/master/includes/CodeGen.Platform.hs#L450-L623<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc%2Fghc%2Fblob%2Fmaster%2Fincludes%2FCodeGen.Platform.hs%23L450&data=02%7C01%7Csimonpj%40microsoft.com%7Cee2fb4d91cfc45ae307808d5e8d5d097%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636670927384447548&sdata=4zBPD6H62ynzybNQWXm3FkFuvZS3Jnvzi98sT69zvmY%3D&reserved=0>
On Fri, Jul 13, 2018 at 10:58 AM Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
Abhiroop
Did anyone reply?
My instinct is this. You want to use the same register (say Xmm reg 3) in different ways. We already have this for ‘VanillaReg’:
data GlobalReg
= VanillaReg -- pointers, unboxed ints and chars
Int -- its number
VGcPtr
| …
data VGcPtr = VGcPtr | VNonGcPtr
We use VanillaReg for both pointers and non-pointers, so (VanillaReg 3 VGcPtr) is register 3 used as a pointer, and (VanillaReg 3 VNonGcPtr) is register 3 used as a non-pointer. And notice that globalRegType looks at this field to decide what type to return.
I think you can do exactly the same: add a field to Xmm that explains how you are gong to divide it up. Would that work?
Simon
From: ghc-devs <ghc-devs-bounces at haskell.org<mailto:ghc-devs-bounces at haskell.org>> On Behalf Of Abhiroop Sarkar
Sent: 27 June 2018 22:32
To: ghc-devs at haskell.org<mailto:ghc-devs at haskell.org>
Subject: Is it possible to enhance the vector STG registers(Xmm, Ymm, Zmm) with more information?
Hello all,
I am currently working on adding support for SIMD operations to the native code generator. One of the roadblocks I faced recently was the definition of the `globalRegType` function in "compiler/cmm/CmmExpr.hs". The `globalRegType` function maps the STG registers to the respective `CmmType` datatype.
For Xmm, Ymm, Zmm registers the function defines globalRegType like this: https://github.com/ghc/ghc/blob/master/compiler/cmm/CmmExpr.hs#L585-L587<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc%2Fghc%2Fblob%2Fmaster%2Fcompiler%2Fcmm%2FCmmExpr.hs%23L585-L587&data=02%7C01%7Csimonpj%40microsoft.com%7Cee2fb4d91cfc45ae307808d5e8d5d097%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636670927384457557&sdata=PRvCQNU2vMMBuI4RJHcXiuy2vHdf9oK5IyzLq%2BroAvA%3D&reserved=0>
Consider the case for an Xmm register, the above definition limits an Xmm register to hold only vectors of size 4. However we can store 2 64-bit Doubles or 16 Int8s or 8 Int16s and so on
The function `globalRegType` is internally called by the function `cmmRegType` (https://github.com/ghc/ghc/blob/838b69032566ce6ab3918d70e8d5e098d0bcee02/compiler/cmm/CmmExpr.hs#L275<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc%2Fghc%2Fblob%2F838b69032566ce6ab3918d70e8d5e098d0bcee02%2Fcompiler%2Fcmm%2FCmmExpr.hs%23L275&data=02%7C01%7Csimonpj%40microsoft.com%7Cee2fb4d91cfc45ae307808d5e8d5d097%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636670927384457557&sdata=uPI1WMQzitwsatfNc5XvO7DpunpziVtE75R3maBVAz4%3D&reserved=0>) which is itself used in a number of places in the x86 code generator.
In fact depending on the result of the `cmmRegType` function is another important function `cmmTypeFormat` defined in Format.hs whose result is used to print the actual assembly instruction.
I have extended all the other Format types to include VectorFormats, however this definition of the `globalRegType` seems incorrect to me. Looking at the signature of the function itself:
`globalRegType :: DynFlags -> GlobalReg -> CmmType`
its actually difficult to predict the CmmType by just looking at the GlobalReg in case of Xmm, Ymm, Zmm. So thats why my original question how do I go about solving this. Should I modify the GlobalReg type to contain more information like Width and Length(for Xmm, Ymm, Zmm) or do I somehow pass the length and width information to the globalRegType function?
Thanks
Abhiroop Sakar
--
Kloona - Coming Soon!
--
Kloona - Coming Soon!
--
Kloona - Coming Soon!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20180713/535f4b2e/attachment.html>
More information about the ghc-devs
mailing list