gem5-users@gem5.org

The gem5 Users mailing list

View all threads

IsSerializeAfter Flag

CP
Chrysanthos Pepi
Mon, Jun 6, 2022 8:45 PM

Howdy,

I’m trying to understand when and why the IsSerializeAfter Flag is set in X86 O3 architecture. I ran the PARSEC benchmark suite and I found out that 15 instructions/micro-ops have set the flag.

Looking through the source code (v21.2.1.1):

src/arch/x86/isa/macroop.isa:
The flag is appended if the “serialize_after” is true. “serialize_after” is true if the serializeAfter method is called but the only method I can find is in rename.cc which doesn’t set the flag.

src/arch/x86/isa/decoder/two_byte_opcodes.isa:
If it’s LFENCE the flag is set.

src/arch/x86/isa/formats/cpuid.isa:
The flag is set to true but on what condition? As its inside of a constructor.

src/arch/x86/isa/operands.isa:
There are some methods (controlReg, squashCheckReg) that return the flag I think but I am not sure how it works.

Any help is more than welcome.

Kind regards,
Chrysanthos Pepi

Howdy, I’m trying to understand when and why the IsSerializeAfter Flag is set in X86 O3 architecture. I ran the PARSEC benchmark suite and I found out that 15 instructions/micro-ops have set the flag. Looking through the source code (v21.2.1.1): src/arch/x86/isa/macroop.isa: The flag is appended if the “serialize_after” is true. “serialize_after” is true if the serializeAfter method is called but the only method I can find is in rename.cc which doesn’t set the flag. src/arch/x86/isa/decoder/two_byte_opcodes.isa: If it’s LFENCE the flag is set. src/arch/x86/isa/formats/cpuid.isa: The flag is set to true but on what condition? As its inside of a constructor. src/arch/x86/isa/operands.isa: There are some methods (controlReg, squashCheckReg) that return the flag I think but I am not sure how it works. Any help is more than welcome. Kind regards, Chrysanthos Pepi
EM
Eliot Moss
Mon, Jun 6, 2022 9:25 PM

On 6/6/2022 4:45 PM, Chrysanthos Pepi wrote:

Howdy,

I’m trying to understand when and why the IsSerializeAfter Flag is set in X86 O3 architecture. I ran
the PARSEC benchmark suite and I found out that 15 instructions/micro-ops have set the flag.

Looking through the source code (v21.2.1.1):

src/arch/x86/isa/macroop.isa:

The flag is appended if the “serialize_after” is true. “serialize_after” is true if the
serializeAfter method is called but the only method I can find is in rename.cc which doesn’t set the
flag.

src/arch/x86/isa/decoder/two_byte_opcodes.isa:

If it’s LFENCE the flag is set.

src/arch/x86/isa/formats/cpuid.isa:

The flag is set to true but on what condition? As its inside of a constructor.

src/arch/x86/isa/operands.isa:

There are some methods (controlReg, squashCheckReg) that return the flag I think but I am not sure
how it works.

Any help is more than welcome.

Kind regards,

Chrysanthos Pepi

I dug into this code recently, bit from a need to understand some of the
synchronization (fencing) but also because I wanted to add support for the
new Intel SERIALIZE instruction (which turned out to be relatively easy).

IsSerializeAfter means that all preceding instructions must have fully
executed before the IsSerializeAfter instruction is released from
instruction fetch.  This is done by insisting that that ROB be empty.
If you poke around, I think you can find this.

IsSerializeBefore means the next instruction is to be considered
IsSerializeAfter - thus it means that the IsSerializeBefore instruction
and all that come befire it, must finish execution before the next
instruction can start.

LFENCE curiously has IsSerializeAfter and a memory ordering fence.
The IsSerializeBefore prevents any preceding load from finishing
later than the LFENCE.  However, the LFENCE and succeeding loads
could compete and pass each other.  The additional memory related
fence prevents that, without being quite as strong as putting both
IsSerializeBefore and IsSerializeAfter.

The semantics of the SERIALIZE instruction are curiously weaker than
LFENCE, apparently needing only IsSerializeAfter.

To completely "corral" an m5_work_begin/end instruction, which was
my desire, I put SERIALIZE both before and after the m5_work_begin.
This gains some precision in one sense, but because it implies fully
flushing the pipelines and such, it will disturb timings so should
be used only if the measured code sequence runs long enough to where
those flushes can be neglected for the measurement purpose at hand.
On an O3 machine "how long does this code sequence take?" does not
have any obvious simple and precise answer :-) ...

If I have my gem5 understanding wrong, I am happy to be corrected
by someone who knows more!

Regards - Eliot Moss

On 6/6/2022 4:45 PM, Chrysanthos Pepi wrote: > Howdy, > > I’m trying to understand when and why the IsSerializeAfter Flag is set in X86 O3 architecture. I ran > the PARSEC benchmark suite and I found out that 15 instructions/micro-ops have set the flag. > > Looking through the source code (v21.2.1.1): > > *_src/arch/x86/isa/macroop.isa:_* > > The flag is appended if the “serialize_after” is true. “serialize_after” is true if the > serializeAfter method is called but the only method I can find is in rename.cc which doesn’t set the > flag. > > *_src/arch/x86/isa/decoder/two_byte_opcodes.isa:_* > > If it’s LFENCE the flag is set. > > *_src/arch/x86/isa/formats/cpuid.isa:_* > > The flag is set to true but on what condition? As its inside of a constructor. > > *_src/arch/x86/isa/operands.isa:_* > > There are some methods (controlReg, squashCheckReg) that return the flag I think but I am not sure > how it works. > > Any help is more than welcome. > > Kind regards, > > Chrysanthos Pepi I dug into this code recently, bit from a need to understand some of the synchronization (fencing) but also because I wanted to add support for the new Intel SERIALIZE instruction (which turned out to be relatively easy). IsSerializeAfter means that all preceding instructions must have fully executed before the IsSerializeAfter instruction is released from instruction fetch. This is done by insisting that that ROB be empty. If you poke around, I think you can find this. IsSerializeBefore means the *next* instruction is to be considered IsSerializeAfter - thus it means that the IsSerializeBefore instruction and all that come befire it, must finish execution before the next instruction can start. LFENCE curiously has IsSerializeAfter *and* a memory ordering fence. The IsSerializeBefore prevents any preceding load from finishing later than the LFENCE. However, the LFENCE and succeeding loads *could* compete and pass each other. The additional memory related fence prevents that, without being quite as strong as putting both IsSerializeBefore and IsSerializeAfter. The semantics of the SERIALIZE instruction are curiously weaker than LFENCE, apparently needing only IsSerializeAfter. To completely "corral" an m5_work_begin/end instruction, which was my desire, I put SERIALIZE both before and after the m5_work_begin. This gains some precision in one sense, but because it implies fully flushing the pipelines and such, it will disturb timings so should be used only if the measured code sequence runs long enough to where those flushes can be neglected for the measurement purpose at hand. On an O3 machine "how long does this code sequence take?" does not have any obvious simple and precise answer :-) ... If I have my gem5 understanding wrong, I am happy to be corrected by someone who knows more! Regards - Eliot Moss