Review Board 2.0.15


x86: fixed branching computation for branch uops that only changes nupc and not npc

Review Request #3790 - Created Jan. 23, 2017 and updated

Information
Santi Galan
gem5
default
Reviewers
Default

Changeset 11801:80af6a1e6beb
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
x86: fixed branching() computation for branch uops that only changes nupc and not npc

When a branch micro-op belongs to a flow and the micro-op does not change the nPC and just updates the nuPC
(like a 'rep movs' flow), branching() function always returns not-taken no matter actual
micro-branch outcome. Provided fix adds to the equation nuPC attribute checking since these kind of branch
micro-op only updates that pointer.

This issue has been found while debugging the performance of a copy-loop implemented with memcopy function. Without the fix, 'rep movss' internal micro-branch was always predicted as not-taken causing an squash event after every branch micro-branch execution.

Using the provided test, branch mispredition went from 1922 without the fix to 7.

I used this command line to evaluate the performance:

./build/X86/gem5.opt configs/example/se.py --cpu-type=detailed --caches --l2cache -c /path/to/binary

This is the source code of the binary:

#include <string.h>
#include "m5op.h"

#define SIZE 15*1024

//arrays are cache aligned
char a [SIZE] __attribute__((aligned(0x40)));
char b [SIZE] __attribute__((aligned(0x40)));

int main ()
{
    //some warmup
    int i;
    for (i = 0; i < SIZE; ++i)
    {
        a[i] = 1;
        b[i] = 2;
    }

    m5_reset_stats(0, 0);
    memcpy(a, b, SIZE);
    m5_exit(0);

    //keep compiler happy
    return 0;
}

Which was compiled with this makefile:

GEM5_PATH=/path/to/gem5

binary: binary.c $(GEM5_PATH)/util/m5/m5op_x86.S
    gcc -o $@ $^ -static -I$(GEM5_PATH)/util/m5
Review request changed
Updated (Jan. 23, 2017, 7:39 a.m.)

Description:

   

Changeset 11801:80af6a1e6beb

    \-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
    x86: fixed branching() computation for branch uops that only changes nupc and not npc

   
   

When a branch micro-op belongs to a flow and the micro-op does not change the nPC and just updates the nuPC

    (like a 'rep movs' flow), branching() function always returns not-taken no matter actual
    micro-branch outcome. Provided fix adds to the equation nuPC attribute checking since these kind of branch
    micro-op only updates that pointer.

   
   

This issue has been found while debugging the performance of a copy-loop implemented with memcopy function. Without the fix, 'rep movss' internal micro-branch was always predicted as not-taken causing an squash event after every branch micro-branch execution.

   
~  

Using the provided thest, branch mispredition went from 1922 without the fix to 7.

  ~

Using the provided test, branch mispredition went from 1922 without the fix to 7.

Testing Done:

   

I used this command line to evaluate the performance:

   
   

   
   
./build/X86/gem5.opt configs/example/se.py --cpu-type=detailed --caches --l2cache -c /path/to/binary
   
   
   

   
   

This is the source code of the binary:

   
   
#include <string.h>
   
#include "m5op.h"
   
   
#define SIZE 15*1024
   
   
//arrays are cache aligned
   
char a [SIZE] __attribute__((aligned(0x40)));
   
char b [SIZE] __attribute__((aligned(0x40)));
   
   
int main ()
   
{
   
    //some warmup
   
    int i;
   
    for (i = 0; i < SIZE; ++i)
   
    {
   
        a[i] = 1;
   
        b[i] = 2;
   
    }
   
~  
    m5_reset_stats();
  ~
    m5_reset_stats(0, 0);
   
    memcpy(a, b, SIZE);
   
    m5_exit(0);
   
   
    //keep compiler happy
   
    return 0;
   
}
   
   
   

   
   

Which was compiled with this makefile:

   
   

   
   
GEM5_PATH=/path/to/gem5
   
   
binary: binary.c $(GEM5_PATH)/util/m5/m5op_x86.S
   
    gcc -o $@ $^ -static -I$(GEM5_PATH)/util/m5
   
Ship it!
Posted (Jan. 23, 2017, 8:38 a.m.)
Ship It!
Ship it!
Posted (Jan. 24, 2017, 12:53 a.m.)
Ship It!
  1. My bad, I am not familiar with the process and I thought that the "Ship it!" button would change somehow the revision state.

    Santi

Ship it!
Posted (Jan. 24, 2017, 7:30 a.m.)
Ship It!
Ship it!
Posted (Jan. 24, 2017, 11:45 p.m.)
Ship It!
  1. Let me comment on this review request to bring it to live since it seems like it has not been applied yet. Is there anything missing in order to be applied?

    Thanks,
    Santi Galan

  2. No. I'll pull it into the repository. Thanks for pinging me on it.