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

Simon Peyton Jones simonpj at
Fri Jul 13 15:12:46 UTC 2018

What is the GlobalVecRegTy field doing?
Don’t you need an Int for the register number, like all the rest?

Generally, sounds good though


From: Abhiroop Sarkar <asiamgenius at>
Sent: 13 July 2018 14:07
To: Simon Peyton Jones <simonpj at>
Cc: ghc-devs at
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.



On Fri, Jul 13, 2018 at 10:58 AM Simon Peyton Jones <simonpj at<mailto:simonpj at>> wrote:

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


   | …

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?


From: ghc-devs <ghc-devs-bounces at<mailto:ghc-devs-bounces at>> On Behalf Of Abhiroop Sarkar
Sent: 27 June 2018 22:32
To: ghc-devs at<mailto:ghc-devs at>
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:<>

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` (<>) 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?

Abhiroop Sakar

Kloona - Coming Soon!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list