Is it possible to enhance the vector STG registers(Xmm, Ymm, Zmm) with more information?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Is it possible to enhance the vector STG registers(Xmm, Ymm, Zmm) with more information?

Abhiroop Sarkar
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

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) 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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Is it possible to enhance the vector STG registers(Xmm, Ymm, Zmm) with more information?

Carter Schonwald
hrmm, i think i can help with this tomorrow/ rest of the week, (esp since i'm one of your mentors :) )

but if other folks have design ideas, more than happy to use as many ideas as possible!

On Wed, Jun 27, 2018 at 5:32 PM Abhiroop Sarkar <[hidden email]> wrote:
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

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) 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
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Is it possible to enhance the vector STG registers(Xmm, Ymm, Zmm) with more information?

GHC - devs mailing list
In reply to this post by Abhiroop Sarkar

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 <[hidden email]> On Behalf Of Abhiroop Sarkar
Sent: 27 June 2018 22:32
To: [hidden email]
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

 

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) 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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Is it possible to enhance the vector STG registers(Xmm, Ymm, Zmm) with more information?

Abhiroop Sarkar
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



On Fri, Jul 13, 2018 at 10:58 AM Simon Peyton Jones <[hidden email]> 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 <[hidden email]> On Behalf Of Abhiroop Sarkar
Sent: 27 June 2018 22:32
To: [hidden email]
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

 

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) 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!

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Is it possible to enhance the vector STG registers(Xmm, Ymm, Zmm) with more information?

GHC - devs mailing list

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 <[hidden email]>
Sent: 13 July 2018 14:07
To: Simon Peyton Jones <[hidden email]>
Cc: [hidden email]
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

 

 

 

On Fri, Jul 13, 2018 at 10:58 AM Simon Peyton Jones <[hidden email]> 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 <[hidden email]> On Behalf Of Abhiroop Sarkar
Sent: 27 June 2018 22:32
To: [hidden email]
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

 

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) 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!


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Is it possible to enhance the vector STG registers(Xmm, Ymm, Zmm) with more information?

Abhiroop Sarkar
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

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 <[hidden email]> 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 <[hidden email]>
Sent: 13 July 2018 14:07
To: Simon Peyton Jones <[hidden email]>
Cc: [hidden email]
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

 

 

 

On Fri, Jul 13, 2018 at 10:58 AM Simon Peyton Jones <[hidden email]> 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 <[hidden email]> On Behalf Of Abhiroop Sarkar
Sent: 27 June 2018 22:32
To: [hidden email]
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

 

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) 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!

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Is it possible to enhance the vector STG registers(Xmm, Ymm, Zmm) with more information?

Abhiroop Sarkar
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


On Fri, Jul 13, 2018 at 4:26 PM Abhiroop Sarkar <[hidden email]> 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

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 <[hidden email]> 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 <[hidden email]>
Sent: 13 July 2018 14:07
To: Simon Peyton Jones <[hidden email]>
Cc: [hidden email]
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

 

 

 

On Fri, Jul 13, 2018 at 10:58 AM Simon Peyton Jones <[hidden email]> 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 <[hidden email]> On Behalf Of Abhiroop Sarkar
Sent: 27 June 2018 22:32
To: [hidden email]
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

 

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) 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!

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: Is it possible to enhance the vector STG registers(Xmm, Ymm, Zmm) with more information?

GHC - devs mailing list

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 <[hidden email]>
Sent: 13 July 2018 16:32
To: Simon Peyton Jones <[hidden email]>
Cc: [hidden email]
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

 

 

On Fri, Jul 13, 2018 at 4:26 PM Abhiroop Sarkar <[hidden email]> 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

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 <[hidden email]> 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 <[hidden email]>
Sent: 13 July 2018 14:07
To: Simon Peyton Jones <[hidden email]>
Cc: [hidden email]
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

 

 

 

On Fri, Jul 13, 2018 at 10:58 AM Simon Peyton Jones <[hidden email]> 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 <[hidden email]> On Behalf Of Abhiroop Sarkar
Sent: 27 June 2018 22:32
To: [hidden email]
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

 

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) 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!


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Is it possible to enhance the vector STG registers(Xmm, Ymm, Zmm) with more information?

Carter Schonwald
Indeed xmm registers can hold richer structures than just scalar floats and doubles.  

They can do 4 32 bit floats or 32bit ints or words 

or 2 64 bit doubles or 64bit ints or words. 

Or scalar 32/64bit ints or words! (Distinct from the gpr registers!)

Xmm registers are the lower half of ymm/ lower quarter of zmm simd registers (when they exist on newer x86-64 cpus )

Agreed, the maybes are definitely going to be removed before end of summer. Though Andreas and I may try to go over things a tad closely in our code reviews 



On Fri, Jul 13, 2018 at 6:22 PM Simon Peyton Jones via ghc-devs <[hidden email]> wrote:

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 <[hidden email]>
Sent: 13 July 2018 16:32


To: Simon Peyton Jones <[hidden email]>
Cc: [hidden email]
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

 

 

On Fri, Jul 13, 2018 at 4:26 PM Abhiroop Sarkar <[hidden email]> 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

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 <[hidden email]> 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 <[hidden email]>
Sent: 13 July 2018 14:07
To: Simon Peyton Jones <[hidden email]>
Cc: [hidden email]
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

 

 

 

On Fri, Jul 13, 2018 at 10:58 AM Simon Peyton Jones <[hidden email]> 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 <[hidden email]> On Behalf Of Abhiroop Sarkar
Sent: 27 June 2018 22:32
To: [hidden email]
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

 

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) 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!

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs