Hi, Thanks for the reply and comments.
Yes, I am asking about the spill size for Float32, as they might be in a snapshot, I asked about the reading and writing such a stack slot as well. It should be 4-byte and the current implement used 8-byte. Could you talk a little bit more on the trouble with Float32x4 and where we eagerly spill Value-size content in the code? Dan wrote a patch to allocate and spill Float32x4 (https://bugzilla.mozilla.org/show_bug.cgi?id=947711), could you give review comments there? Thanks -Haitao On Fri, Dec 13, 2013 at 05:12:29AM -0800, Nicolas B. Pierron wrote: > On 12/12/2013 06:51 PM, Feng, Haitao wrote: > >Why did not we use 4-byte stack slot and 4-byte snapshot slot for > >float32 and use movss instead of movsd? > > Can you be more precise? The Snapshot slots are unlikely to be 4 > bytes, because they are written into a compact buffer and they are > not directly addressable. Also the snapshot slots are used to > indicate the location, such as if it is in a register or on the > stack. > > If you are talking about the spill of register made for bailouts, > then, we will have trouble with Float32x4, as we are eagerly > spilling Value-size content at the moment. This should not be a big > deal to spill the full [xy]mm registers instead of the low parts. > > >If we introduced FLOAT32_REG > >type in the LDefinition::Type and FLOAT32_REG in the LAllocation::Kind, > >it should be relatively easier to add Float32x4_REG. > > I will talk about the MIRType, as this is the example I took at the > time , but I think we can do the same thing for the LAllocation and > LDefinition. > > This is one thing I discuss with Benjamin Bouvier before he added > the Float32. We should think of the future when doing such design. > At the moment we are running conditionals to check if this is a > float32 or a double. As we have many vector sizes (1,2,4,8) and > vector type (double, float, uint8, uint32), I think it would be > better to abstract all of these and make the MIRType a structure > which is using a bit-field to represent all of these vector type. > > struct MIRType { > enum Type { > TYPE_VALUE, > …, > TYPE_DOUBLE, > TYPE_FLOAT, > TYPE_INT8, > TYPE_INT16, > TYPE_INT32 > }; > > // Useful for finally supporting unsigned int 8 > // and URSH without hacks. > const uint32_t signedValue:1; > > const uint32_t padding_: 12; > > // Shift index to obtain the number of element in the vector. > const uint32_t vectorScale: 3; > > // use uint32_t instead of Type because of a > // windows compiler issue. > const uint32_t type:16; > }; > > static const MIRType MIRType_Value = > {true, /* 1 << */ 0, MIRType::TYPE_VALUE}; > static const MIRType MIRType_Float32x4 = > {true, /* 1 << */ 2, MIRType::TYPE_FLOAT}; > static const MIRType MIRType_UInt8x4 = > {false, /* 1 << */ 2, MIRType::TYPE_INT8}; > > -- > Nicolas B. Pierron > _______________________________________________ > dev-tech-js-engine-internals mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
