[gem5-dev] Review Request 3745: scons: fix how flags are passed to the compiler when more than one sanitizer at a time is enabled

[Joe Gross]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3745/
---

Review request for Default and Tony Gutierrez.


Repository: gem5


Description
---

scons: fix sanitizer flags with multiple sanitizers

There has been some problem when using address and undefined-behavior 
sanitizers at the same time.
This patch will look for the special case where both are enabled at once and 
change the flags passed
to the compiler to reflect this.


Diffs
-

  src/SConscript 9e5050028323260c6d2211d7158ac4a4145ed8bc 

Diff: http://reviews.gem5.org/r/3745/diff/


Testing
---

local build


Thanks,

Joe Gross

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3696: syscall_emul: [PATCH 15/22] add clone/execve for threading and multiprocess simulations

[Brandon Potter]

> On Nov. 15, 2016, 2:03 a.m., Alexandru Dutu wrote:
> > src/sim/process.cc, line 148
> > 
> >
> > Does memState need to be dynamically allocated?

Yes, the memState need to be able to be dynamically created and shared between 
Processes to simulate threads.


> On Nov. 15, 2016, 2:03 a.m., Alexandru Dutu wrote:
> > src/sim/syscall_emul.hh, line 1220
> > 
> >
> > Should these commented lines be removed?

I'm leaving them in place in case someone wants to implement this for sparc. 
The registers don't show up in the header file for sparc and I had a bit of 
trouble the compiler to not complain about them.

Also, I only put effort in getting the pthread support to work for x86. The 
other ISAs still need work, but the code should compile for all of them now.


> On Nov. 15, 2016, 2:03 a.m., Alexandru Dutu wrote:
> > src/sim/syscall_emul.hh, line 1768
> > 
> >
> > Ranged for will work here as well.

fds is not an iterable class


- Brandon


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3696/#review9071
---


On Nov. 14, 2016, 8:37 p.m., Brandon Potter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3696/
> ---
> 
> (Updated Nov. 14, 2016, 8:37 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11722:6fea3eedd891
> ---
> syscall_emul: [PATCH 15/22] add clone/execve for threading and multiprocess 
> simulations
> 
> Modifies the clone system call and adds execve system call. Requires allowing
> processes to steal thread contexts from other processes in the same system
> object and the ability to detach pieces of process state (such as MemState)
> to allow dynamic sharing.
> 
> 
> Diffs
> -
> 
>   src/sim/syscall_emul.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/syscall_desc.hh PRE-CREATION 
>   src/sim/syscall_emul.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/process.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/mem/page_table.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/mem/se_translating_port_proxy.hh 
> c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/sim/Process.py c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/cpu/thread_state.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/mem/page_table.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/cpu/thread_context.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/cpu/o3/thread_context.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/cpu/simple_thread.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/x86/types.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/cpu/checker/thread_context.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/x86/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/x86/linux/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/x86/process.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/x86/linux/process.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/sparc/process.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/sparc/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/sparc/linux/syscalls.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/mips/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/power/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/arm/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/generic/types.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/arch/arm/linux/process.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3696/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Brandon Potter
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3705: dev: Fix buffer length when unserializing an eth pkt

[Michael LeBeane]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3705/
---

(Updated Nov. 23, 2016, 5:36 p.m.)


Review request for Default.


Repository: gem5


Description
---

Changeset 11705:008f04dcc085
---
dev: Fix buffer length when unserializing an eth pkt
Changeset 11701 only serialized the useful portion of of an ethernet packets'
payload.  However, the device models expect each ethernet packet to contain
a 16KB buffer, even if there is no data in it.  This patch adds a 'bufLength'
field to EthPacketData so the original size of the packet buffer can always be
unserialized.

Reported-by: Gabor Dozsa 


Diffs (updated)
-

  src/dev/net/etherpkt.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
  src/dev/net/etherpkt.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
  src/dev/net/i8254xGBe.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
  src/dev/net/ns_gige.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
  src/dev/net/sinic.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 

Diff: http://reviews.gem5.org/r/3705/diff/


Testing
---


Thanks,

Michael LeBeane

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3744: cpu: Remove branch predictor function predictInOrder

[Arthur Perais]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3744/#review9165
---

Ship it!


Ship It!

- Arthur Perais


On nov. 23, 2016, 4:10 après-midi, Jason Lowe-Power wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3744/
> ---
> 
> (Updated nov. 23, 2016, 4:10 après-midi)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> cpu: Remove branch predictor function predictInOrder
> 
> This function was used by the now-defunct InOrderCPU model. Since this
> model is no longer in gem5, this function was not called from anywhere in
> the code.
> 
> 
> Diffs
> -
> 
>   src/cpu/pred/bpred_unit.hh 9e5050028323 
>   src/cpu/pred/bpred_unit.cc 9e5050028323 
> 
> Diff: http://reviews.gem5.org/r/3744/diff/
> 
> 
> Testing
> ---
> 
> Compiles and se mode tests run.
> 
> 
> Thanks,
> 
> Jason Lowe-Power
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3744: cpu: Remove branch predictor function predictInOrder

[Nathanael Premillieu]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3744/#review9164
---

Ship it!


Ship It!

- Nathanael Premillieu


On Nov. 23, 2016, 4:10 p.m., Jason Lowe-Power wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3744/
> ---
> 
> (Updated Nov. 23, 2016, 4:10 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> cpu: Remove branch predictor function predictInOrder
> 
> This function was used by the now-defunct InOrderCPU model. Since this
> model is no longer in gem5, this function was not called from anywhere in
> the code.
> 
> 
> Diffs
> -
> 
>   src/cpu/pred/bpred_unit.hh 9e5050028323 
>   src/cpu/pred/bpred_unit.cc 9e5050028323 
> 
> Diff: http://reviews.gem5.org/r/3744/diff/
> 
> 
> Testing
> ---
> 
> Compiles and se mode tests run.
> 
> 
> Thanks,
> 
> Jason Lowe-Power
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3744: cpu: Remove branch predictor function predictInOrder

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3744/
---

Review request for Default.


Repository: gem5


Description
---

cpu: Remove branch predictor function predictInOrder

This function was used by the now-defunct InOrderCPU model. Since this
model is no longer in gem5, this function was not called from anywhere in
the code.


Diffs
-

  src/cpu/pred/bpred_unit.hh 9e5050028323 
  src/cpu/pred/bpred_unit.cc 9e5050028323 

Diff: http://reviews.gem5.org/r/3744/diff/


Testing
---

Compiles and se mode tests run.


Thanks,

Jason Lowe-Power

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3743: cpu: implement L-TAGE branch predictor

[Arthur Perais]

> On nov. 23, 2016, 3:17 après-midi, Jason Lowe-Power wrote:
> > src/cpu/pred/BranchPredictor.py, line 100
> > 
> >
> > Comment is now wrong.
> > 
> > Also, does it make more sense to call this histBufferEntries (or 
> > histBufferBits) and make the default 2**21? (or would it be 2**21*8? <-- 
> > this is the confusion.) 
> > 
> > I think it would be more clear to use bits or entries, personally. But 
> > if the branch predictor papers usually talk about the history buffer in 
> > terms of bytes instead of bits, I guess the current version makes more 
> > sense.
> 
> Nathanael Premillieu wrote:
> This big buffer is just a software structure and it does not represent a 
> hardware one.
> It is just done like this to simplify the management of the branch 
> history and avoid copying those bits too often.
> The modeled hardware history is implemented as a sliding window on this 
> big buffer.

In effect, the predictor will create an array of 2**21 entries, each entry 
containing an uint8_t, so the buffer is indeed 2MB, even though it contains 
2Mbits of history information. As Nathanael pointed out, this is a trick to 
avoid using a linked-list/deque which is more costly. The buffer is much bigger 
than the actual history size to remove bound checks and wrap-around adjustment 
that would be necessary with a circular buffer in *most* places where it is 
accessed, at the cost of copying the whole history from the beginning to the 
end of the buffer when the buffer is filled (so it has to be big enough to 
amortize the cost of the copy).

If you really think it should be changed to Param.Unsigned, I'll change it. 
I'll wait for some input before posting the version with the correct comment 
(my bad).


- Arthur


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3743/#review9160
---


On nov. 23, 2016, 2:52 après-midi, Arthur Perais wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3743/
> ---
> 
> (Updated nov. 23, 2016, 2:52 après-midi)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11707:1d085f66c4ca
> ---
> 
> cpu: implement an L-TAGE branch predictor
> 
> This patch implements an L-TAGE predictor, based on André Seznec's code 
> available from 
> CBP-2 
> (http://hpca23.cse.tamu.edu/taco/camino/cbp2/cbp-src/realistic-seznec.h). The
> patch also changes the default branch predictor of o3 from the tournament 
> predictor
> to L-TAGE.
> 
> This patch requires patch #3727 (http://reviews.gem5.org/r/3727/) to compile.
> 
> 
> Diffs
> -
> 
>   src/cpu/pred/BranchPredictor.py 1d085f66c4ca 
>   src/cpu/pred/SConscript 1d085f66c4ca 
>   src/cpu/pred/ltage.hh PRE-CREATION 
>   src/cpu/pred/ltage.cc PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3743/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Arthur Perais
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3743: cpu: implement L-TAGE branch predictor

[Nathanael Premillieu]

> On Nov. 23, 2016, 3:17 p.m., Jason Lowe-Power wrote:
> > src/cpu/pred/BranchPredictor.py, line 100
> > 
> >
> > Comment is now wrong.
> > 
> > Also, does it make more sense to call this histBufferEntries (or 
> > histBufferBits) and make the default 2**21? (or would it be 2**21*8? <-- 
> > this is the confusion.) 
> > 
> > I think it would be more clear to use bits or entries, personally. But 
> > if the branch predictor papers usually talk about the history buffer in 
> > terms of bytes instead of bits, I guess the current version makes more 
> > sense.

This big buffer is just a software structure and it does not represent a 
hardware one.
It is just done like this to simplify the management of the branch history and 
avoid copying those bits too often.
The modeled hardware history is implemented as a sliding window on this big 
buffer.


- Nathanael


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3743/#review9160
---


On Nov. 23, 2016, 2:52 p.m., Arthur Perais wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3743/
> ---
> 
> (Updated Nov. 23, 2016, 2:52 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11707:1d085f66c4ca
> ---
> 
> cpu: implement an L-TAGE branch predictor
> 
> This patch implements an L-TAGE predictor, based on André Seznec's code 
> available from 
> CBP-2 
> (http://hpca23.cse.tamu.edu/taco/camino/cbp2/cbp-src/realistic-seznec.h). The
> patch also changes the default branch predictor of o3 from the tournament 
> predictor
> to L-TAGE.
> 
> This patch requires patch #3727 (http://reviews.gem5.org/r/3727/) to compile.
> 
> 
> Diffs
> -
> 
>   src/cpu/pred/BranchPredictor.py 1d085f66c4ca 
>   src/cpu/pred/SConscript 1d085f66c4ca 
>   src/cpu/pred/ltage.hh PRE-CREATION 
>   src/cpu/pred/ltage.cc PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3743/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Arthur Perais
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3705: dev: Fix buffer length when unserializing an eth pkt

[Gabor Dozsa]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3705/#review9157
---



src/dev/net/dist_etherlink.cc (line 237)


No need for the fixed 16KB buffer size here. (No further data will be 
appended to the packet.) You might allocate space only for the existing data in 
the unserialize() instead (see my comments at EthPacketData::unserialize()).



src/dev/net/dist_iface.cc (line 537)


The same here - no need for fixed 16KB buffer size.



src/dev/net/etherlink.cc (line 238)


The same here - no need for fixed 16KB buffer size.



src/dev/net/etherlink.cc (line 254)


The same here - no need for fixed 16KB buffer size.



src/dev/net/etherpkt.cc (line 54)


It might make sense to check that the current bufLength value is either 
zero or not smaller than the new one read from the checkpoint. Otherwise, we 
might overflow the buffer below at arrayParamIn(...).



src/dev/net/etherpkt.cc (line 55)


If we have an old checkpoint then this assertion may fire unless we always 
allocate the fixed size buffer before unserializing any eth packet (which would 
be nice to avoid). This could be fixed by using 'length' as buffer size if 
'bufLength' is not present in the checkpoint.



src/dev/net/ns_gige.cc (line 2367)


No need to allocate the fix 16KB buffer for an rx packet.



src/dev/net/pktfifo.cc (line 80)


No need for fixed 16KB size here either. PacketFifo is only used to store 
"finalized" eth packets (i.e. no further data will be appended to the packets).


- Gabor Dozsa


On Nov. 21, 2016, 6:57 p.m., Michael LeBeane wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3705/
> ---
> 
> (Updated Nov. 21, 2016, 6:57 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11705:008f04dcc085
> ---
> dev: Fix buffer length when unserializing an eth pkt
> Changeset 11701 only serialized the useful portion of of an ethernet packets'
> payload.  However, the device models expect each ethernet packet to contain
> a 16KB buffer, even if there is no data in it.  This patch adds a 'bufLength'
> field to EthPacketData so the original size of the packet buffer can always be
> unserialized.
> 
> Reported-by: Gabor Dozsa 
> 
> 
> Diffs
> -
> 
>   src/dev/net/dist_etherlink.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/dev/net/dist_iface.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/dev/net/etherlink.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/dev/net/etherpkt.hh c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/dev/net/etherpkt.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/dev/net/i8254xGBe.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/dev/net/ns_gige.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/dev/net/pktfifo.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
>   src/dev/net/sinic.cc c38fcdaa5fe508dbb18cc084e758ad0ce8e2e2f4 
> 
> Diff: http://reviews.gem5.org/r/3705/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Michael LeBeane
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3710: cpu: Resolve targets of predicted 'taken' conditional direct branches at decode (o3)

[Jason Lowe-Power]

> On Nov. 22, 2016, 5:51 p.m., Jason Lowe-Power wrote:
> > The error you're seeing is because you don't have Google's protobuf library 
> > installed. Though it has no affect on what you're seeing.
> > 
> > Can you run the full system linux boot regression with O3 to be sure that 
> > it still works correctly? This is a more rigorous test than any SE mode 
> > tests.
> 
> Arthur Perais wrote:
> Here it is. As expected, nothing changes regarding performance or 
> correctness (as proxied by sim_ints and sim_ops).
> Of course, the number of branches resolved at Decode increases 
> dramatically (omitted here).
> 
> * 
> build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-minor: passed.
> 
> --- long/fs/10.linux-boot/alpha/linux/tsunami-o3 ---
> *** gem5: OK
> *** stat_diff: FAILURE: Statistics mismatch
> Statistics mismatch
> Maximum error magnitude: +609.982116%
> 
>   Reference  New Value   Abs Diff   Pct 
> Chg
> Key statistics:
> 
>   host_inst_rate 239114 252487  13373
> +5.59%
>   host_mem_usage 338260 509164 170904   
> +50.52%
>   sim_insts52969539   52969539  0
> +0.00%
>   sim_ops  52969539   52969539  0
> +0.00%
>   sim_ticks  1865011607500 1865011901500 294000   
>  +0.00%
>   system.cpu.commit.committedInsts   56159642   56159642  0
> +0.00%
>   system.cpu.commit.committedOps   56159642   56159642  0
> +0.00%
>   system.cpu.committedInsts52969539   52969539  0
> +0.00%
>   system.cpu.committedOps  52969539   52969539  0
> +0.00%
>   system.cpu.ipc   0.408632   0.408630  -0.02
> -0.00%
>   system.cpu.ipc_total 0.408632   0.408630  -0.02
> -0.00%
> 
> * build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-o3: 
> CHANGED!
> 
> --- long/fs/10.linux-boot/alpha/linux/tsunami-o3-dual ---
> *** gem5: OK
> *** stat_diff: FAILURE: Statistics mismatch
> Statistics mismatch
> Maximum error magnitude: +654.222399%
> 
>   Reference  New Value   Abs Diff   Pct 
> Chg
> Key statistics:
> 
>   host_inst_rate 237406 253837  16431
> +6.92%
>   host_mem_usage 342872 515808 172936   
> +50.44%
>   sim_insts56676315   56676490175
> +0.00%
>   sim_ops  56676315   56676490175
> +0.00%
>   sim_ticks  1907549438500 1907550384500 946000   
>  +0.00%
>   system.cpu0.commit.committedInsts   49598051   49598186135
> +0.00%
>   system.cpu0.commit.committedOps   49598051   49598186135
> +0.00%
>   system.cpu0.committedInsts   46714728   46714853125
> +0.00%
>   system.cpu0.committedOps 46714728   46714853125
> +0.00%
>   system.cpu0.ipc  0.390977   0.390991   0.14
> +0.00%
>   system.cpu0.ipc_total0.390977   0.390991   0.14
> +0.00%
>   system.cpu1.commit.committedInsts   10447204   10447254 50
> +0.00%
>   system.cpu1.commit.committedOps   10447204   10447254 50
> +0.00%
>   system.cpu1.committedInsts99615879961637 50
> +0.00%
>   system.cpu1.committedOps  99615879961637 50
> +0.00%
>   system.cpu1.ipc  0.567818   0.567762  -0.56
> -0.01%
>   system.cpu1.ipc_total0.567818   0.567762  -0.56
> -0.01%
> 
> * 
> build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-o3-dual: 
> CHANGED!
> 
> * 
> build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-switcheroo-full:
>  passed.

Thanks!


- Jason


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3710/#review9152
---


On Nov. 18, 2016, 3:21 p.m., Arthur Perais wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3710/
> ---
> 
> (Updated Nov. 18, 2016, 3:21 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11707:1d085f66c4ca
> ---
> cpu: Resolve targets of predicted 'taken' conditional direct branches at 
> decode (o3)
> 
> The target of taken conditional direct branches does not 
> need to be resolved in IEW

Re: [gem5-dev] Patches of TAGE branch predictor

[Jason Lowe-Power]

I think that makes sense. I'll put a patch on RB for this soon.

Jason

On Wed, Nov 23, 2016 at 5:09 AM Fernando Endo 
wrote:

> Hi all,
>
> Then, considering Arthur's answer, I suppose that we can remove
> BPredUnit::predictInOrder() rather than updating and not testing it.
>
> Regards,
>
> --
> Fernando A. Endo, Post-doc
>
> INRIA Rennes-Bretagne Atlantique
> France
>
>
> 2016-11-21 19:19 GMT+01:00 Arthur Perais :
>
> > I suppose it was called by the InOrder CPU once upon a time. Now the
> Minor
> > CPU uses the same branch prediction code as the o3 CPU, which may have
> led
> > to the current inconsistencies in how branch predictors handle
> out-of-order
> > mispredictions (or not :)).
> >
> > I've submitted a patch regarding this recently (
> > http://reviews.gem5.org/r/3727/), feel free to take a look.
> >
> > Arthur.
> >
> >
> >
> > Le 21/11/2016 à 16:40, Jason Lowe-Power a écrit :
> >
> >> Hi Fernando,
> >>
> >> I don't know what he original use of predictInOrder was, but you're
> right,
> >> it doesn't look like it's in use now. You may be able to figure out what
> >> it
> >> was used for by inferring its function from the code.
> >>
> >> Jason
> >>
> >> On Sun, Nov 13, 2016 at 2:37 PM Jason Lowe-Power 
> >> wrote:
> >>
> >> Hi Fernando,
> >>>
> >>> I have no idea, off the top of my head. I'd have to look into the code
> >>> and/or the history of the file to figure it out.
> >>>
> >>> I'm busy with an ISCA submission right now, but I can find time to look
> >>> into this in a week or so.
> >>>
> >>> Cheers,
> >>> Jason
> >>>
> >>> On Sun, Nov 13, 2016 at 2:26 PM Fernando Endo <
> fernando.en...@gmail.com>
> >>> wrote:
> >>>
> >>> Hi Jason,
> >>>
> >>> I've been working a bit on the integration, and I wondered what is and
> >>> where this method is used:
> >>>
> >>> BPredUnit::predictInOrder()
> >>>
> >>> I greped the source and built code and did not find a calling point.
> >>>
> >>> Thanks,
> >>>
> >>> --
> >>> Fernando A. Endo, Post-doc
> >>>
> >>> INRIA Rennes-Bretagne Atlantique
> >>> France
> >>>
> >>>
> >>> 2016-11-06 21:38 GMT+01:00 Jason Lowe-Power :
> >>>
> >>> Hi Fernando,
> 
>  Yes, it seems like a good idea to include a TAGE predictor in gem5.
> 
> >>> Please
> >>>
>  make patches and post them to the reviewboard. We welcome the
> 
> >>> contribution.
> >>>
>  Additionally, I believe there was a recent email about a possible bug
> 
> >>> when
> >>>
>  updating the branch predictor state on a mis-speculation. If you're
>  familiar with this code, or know of a fix for this, we would
> appreciate
>  a
>  patch. Or, if it's actually not broken, that would be great, too. It's
> 
> >>> part
> >>>
>  of the code that I'm not very familiar with.
> 
>  Cheers,
>  Jason
> 
>  On Fri, Nov 4, 2016 at 9:46 AM Fernando Endo <
> fernando.en...@gmail.com>
>  wrote:
> 
>  Hello all,
> 
>  I'd like to know if the gem5 community would like to have a TAGE
> branch
>  prediction in gem5.
>  In my branch it seems to be working, so if you give me a positive
> 
> >>> feedback
> >>>
>  I may spend some spare time to rebase and test the patch over
>  mainstream.
> 
>  More specifically, I took the CBP2016 winner and removed local
>  prediction
>  tables. This specific version is called TAGE-GSC (Global Statistical
>  Corrector) and should go to src/cpu/pred/tage-gsc.hh. This file is
>  functionally equivalent to the original CBP2016 winner and can be
> 
> >>> compared
> >>>
>  against it without modification. Then, a glue code was implemented in
>  src/cpu/pred/TAGE.hh and src/cpu/pred/TAGE.cc, making tage-gsc.hh to
>  work
>  in gem5.
> 
>  I validated the gem5 implementation by comparing the predictor at
> fetch
>  with a validator at commit. The prediction tables must be the same.
> 
>  Regards,
> 
>  --
>  Fernando A. Endo, Post-doc
> 
>  INRIA Rennes-Bretagne Atlantique
>  France
>  ___
>  gem5-dev mailing list
>  gem5-dev@gem5.org
>  http://m5sim.org/mailman/listinfo/gem5-dev
>  ___
>  gem5-dev mailing list
>  gem5-dev@gem5.org
>  http://m5sim.org/mailman/listinfo/gem5-dev
> 
>  ___
> >>> gem5-dev mailing list
> >>> gem5-dev@gem5.org
> >>> http://m5sim.org/mailman/listinfo/gem5-dev
> >>>
> >>>
> >>> ___
> >> gem5-dev mailing list
> >> gem5-dev@gem5.org
> >> http://m5sim.org/mailman/listinfo/gem5-dev
> >>
> >
> > ___
> > gem5-dev mailing list
> > gem5-dev@gem5.org
> > http://m5sim.org/mailman/listinfo/gem5-dev
> >
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>
___

Re: [gem5-dev] Review Request 3743: cpu: implement L-TAGE branch predictor

[Nathanael Premillieu]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3743/#review9159
---

Ship it!


Ship It!

- Nathanael Premillieu


On Nov. 23, 2016, 2:52 p.m., Arthur Perais wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3743/
> ---
> 
> (Updated Nov. 23, 2016, 2:52 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11707:1d085f66c4ca
> ---
> 
> cpu: implement an L-TAGE branch predictor
> 
> This patch implements an L-TAGE predictor, based on André Seznec's code 
> available from 
> CBP-2 
> (http://hpca23.cse.tamu.edu/taco/camino/cbp2/cbp-src/realistic-seznec.h). The
> patch also changes the default branch predictor of o3 from the tournament 
> predictor
> to L-TAGE.
> 
> This patch requires patch #3727 (http://reviews.gem5.org/r/3727/) to compile.
> 
> 
> Diffs
> -
> 
>   src/cpu/pred/BranchPredictor.py 1d085f66c4ca 
>   src/cpu/pred/SConscript 1d085f66c4ca 
>   src/cpu/pred/ltage.hh PRE-CREATION 
>   src/cpu/pred/ltage.cc PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3743/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Arthur Perais
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3743: cpu: implement L-TAGE branch predictor

[Jason Lowe-Power]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3743/#review9160
---


Thanks for the updates. I'm still not clear on the histBufferSize (as detailed 
below).


src/cpu/pred/BranchPredictor.py (line 100)


Comment is now wrong.

Also, does it make more sense to call this histBufferEntries (or 
histBufferBits) and make the default 2**21? (or would it be 2**21*8? <-- this 
is the confusion.) 

I think it would be more clear to use bits or entries, personally. But if 
the branch predictor papers usually talk about the history buffer in terms of 
bytes instead of bits, I guess the current version makes more sense.


Thanks

- Jason Lowe-Power


On Nov. 23, 2016, 2:52 p.m., Arthur Perais wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3743/
> ---
> 
> (Updated Nov. 23, 2016, 2:52 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11707:1d085f66c4ca
> ---
> 
> cpu: implement an L-TAGE branch predictor
> 
> This patch implements an L-TAGE predictor, based on André Seznec's code 
> available from 
> CBP-2 
> (http://hpca23.cse.tamu.edu/taco/camino/cbp2/cbp-src/realistic-seznec.h). The
> patch also changes the default branch predictor of o3 from the tournament 
> predictor
> to L-TAGE.
> 
> This patch requires patch #3727 (http://reviews.gem5.org/r/3727/) to compile.
> 
> 
> Diffs
> -
> 
>   src/cpu/pred/BranchPredictor.py 1d085f66c4ca 
>   src/cpu/pred/SConscript 1d085f66c4ca 
>   src/cpu/pred/ltage.hh PRE-CREATION 
>   src/cpu/pred/ltage.cc PRE-CREATION 
> 
> Diff: http://reviews.gem5.org/r/3743/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Arthur Perais
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3743: cpu: implement L-TAGE branch predictor

[Arthur Perais]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3743/
---

(Updated nov. 23, 2016, 2:52 après-midi)


Review request for Default.


Changes
---

Modified patch according to comments (Tournament is still default, added 
comments, history size).


Repository: gem5


Description
---

Changeset 11707:1d085f66c4ca
---

cpu: implement an L-TAGE branch predictor

This patch implements an L-TAGE predictor, based on André Seznec's code 
available from 
CBP-2 (http://hpca23.cse.tamu.edu/taco/camino/cbp2/cbp-src/realistic-seznec.h). 
The
patch also changes the default branch predictor of o3 from the tournament 
predictor
to L-TAGE.

This patch requires patch #3727 (http://reviews.gem5.org/r/3727/) to compile.


Diffs (updated)
-

  src/cpu/pred/BranchPredictor.py 1d085f66c4ca 
  src/cpu/pred/SConscript 1d085f66c4ca 
  src/cpu/pred/ltage.hh PRE-CREATION 
  src/cpu/pred/ltage.cc PRE-CREATION 

Diff: http://reviews.gem5.org/r/3743/diff/


Testing
---


Thanks,

Arthur Perais

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3710: cpu: Resolve targets of predicted 'taken' conditional direct branches at decode (o3)

[Arthur Perais]

> On nov. 22, 2016, 5:51 après-midi, Jason Lowe-Power wrote:
> > The error you're seeing is because you don't have Google's protobuf library 
> > installed. Though it has no affect on what you're seeing.
> > 
> > Can you run the full system linux boot regression with O3 to be sure that 
> > it still works correctly? This is a more rigorous test than any SE mode 
> > tests.

Here it is. As expected, nothing changes regarding performance or correctness 
(as proxied by sim_ints and sim_ops).
Of course, the number of branches resolved at Decode increases dramatically 
(omitted here).

* build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-minor: 
passed.

--- long/fs/10.linux-boot/alpha/linux/tsunami-o3 ---
*** gem5: OK
*** stat_diff: FAILURE: Statistics mismatch
Statistics mismatch
Maximum error magnitude: +609.982116%

  Reference  New Value   Abs Diff   Pct Chg
Key statistics:

  host_inst_rate 239114 252487  13373+5.59%
  host_mem_usage 338260 509164 170904   +50.52%
  sim_insts52969539   52969539  0+0.00%
  sim_ops  52969539   52969539  0+0.00%
  sim_ticks  1865011607500 1865011901500 294000
+0.00%
  system.cpu.commit.committedInsts   56159642   56159642  0+0.00%
  system.cpu.commit.committedOps   56159642   56159642  0+0.00%
  system.cpu.committedInsts52969539   52969539  0+0.00%
  system.cpu.committedOps  52969539   52969539  0+0.00%
  system.cpu.ipc   0.408632   0.408630  -0.02-0.00%
  system.cpu.ipc_total 0.408632   0.408630  -0.02-0.00%

* build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-o3: 
CHANGED!

--- long/fs/10.linux-boot/alpha/linux/tsunami-o3-dual ---
*** gem5: OK
*** stat_diff: FAILURE: Statistics mismatch
Statistics mismatch
Maximum error magnitude: +654.222399%

  Reference  New Value   Abs Diff   Pct Chg
Key statistics:

  host_inst_rate 237406 253837  16431+6.92%
  host_mem_usage 342872 515808 172936   +50.44%
  sim_insts56676315   56676490175+0.00%
  sim_ops  56676315   56676490175+0.00%
  sim_ticks  1907549438500 1907550384500 946000
+0.00%
  system.cpu0.commit.committedInsts   49598051   49598186135+0.00%
  system.cpu0.commit.committedOps   49598051   49598186135+0.00%
  system.cpu0.committedInsts   46714728   46714853125+0.00%
  system.cpu0.committedOps 46714728   46714853125+0.00%
  system.cpu0.ipc  0.390977   0.390991   0.14+0.00%
  system.cpu0.ipc_total0.390977   0.390991   0.14+0.00%
  system.cpu1.commit.committedInsts   10447204   10447254 50+0.00%
  system.cpu1.commit.committedOps   10447204   10447254 50+0.00%
  system.cpu1.committedInsts99615879961637 50+0.00%
  system.cpu1.committedOps  99615879961637 50+0.00%
  system.cpu1.ipc  0.567818   0.567762  -0.56-0.01%
  system.cpu1.ipc_total0.567818   0.567762  -0.56-0.01%

* build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-o3-dual: 
CHANGED!

* 
build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-switcheroo-full:
 passed.


- Arthur


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3710/#review9152
---


On nov. 18, 2016, 3:21 après-midi, Arthur Perais wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3710/
> ---
> 
> (Updated nov. 18, 2016, 3:21 après-midi)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11707:1d085f66c4ca
> ---
> cpu: Resolve targets of predicted 'taken' conditional direct branches at 
> decode (o3)
> 
> The target of taken conditional direct branches does not 
> need to be resolved in IEW: the target can be computed at 
> decode, usually using the decoded instruction word and the PC.
> 
> The higher-than-necessary penalty is taken only on conditional
> branches that are predicted taken but miss in the BTB. Thus, 
> this is mostly inconsequential on IPC if the BTB is big/associative 
> enough (fewer capacity/conflict misses). Nonetheless, what gem5 
> simulates is not representative of how conditional branch targets 
> can be handled.
> 
> 
> Diffs

Re: [gem5-dev] ReviewBoard full text search

[Fernando Endo]

Hi,

Without the text search it is not easy to know if someone already posted
the same or similar patch. So, I'm for it, but not sure if it can be that
useful.

Regards,

--
Fernando A. Endo, Post-doc

INRIA Rennes-Bretagne Atlantique
France


2016-11-21 17:34 GMT+01:00 Jason Lowe-Power :

> Hi all,
>
> Is there any reason we don't have full text search enabled on reviewboard?
> Did we accidentally overlook it, or does it strain our server too much?
> Something else?
>
> https://www.reviewboard.org/docs/manual/dev/users/
> searching/full-text-search/
>
> I've been bitten many time by knowing something was posted to reviewboard,
> but I've been unable to find it easily.
>
> Thanks,
> Jason
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Patches of TAGE branch predictor

[Fernando Endo]

Hi all,

Then, considering Arthur's answer, I suppose that we can remove
BPredUnit::predictInOrder() rather than updating and not testing it.

Regards,

--
Fernando A. Endo, Post-doc

INRIA Rennes-Bretagne Atlantique
France


2016-11-21 19:19 GMT+01:00 Arthur Perais :

> I suppose it was called by the InOrder CPU once upon a time. Now the Minor
> CPU uses the same branch prediction code as the o3 CPU, which may have led
> to the current inconsistencies in how branch predictors handle out-of-order
> mispredictions (or not :)).
>
> I've submitted a patch regarding this recently (
> http://reviews.gem5.org/r/3727/), feel free to take a look.
>
> Arthur.
>
>
>
> Le 21/11/2016 à 16:40, Jason Lowe-Power a écrit :
>
>> Hi Fernando,
>>
>> I don't know what he original use of predictInOrder was, but you're right,
>> it doesn't look like it's in use now. You may be able to figure out what
>> it
>> was used for by inferring its function from the code.
>>
>> Jason
>>
>> On Sun, Nov 13, 2016 at 2:37 PM Jason Lowe-Power 
>> wrote:
>>
>> Hi Fernando,
>>>
>>> I have no idea, off the top of my head. I'd have to look into the code
>>> and/or the history of the file to figure it out.
>>>
>>> I'm busy with an ISCA submission right now, but I can find time to look
>>> into this in a week or so.
>>>
>>> Cheers,
>>> Jason
>>>
>>> On Sun, Nov 13, 2016 at 2:26 PM Fernando Endo 
>>> wrote:
>>>
>>> Hi Jason,
>>>
>>> I've been working a bit on the integration, and I wondered what is and
>>> where this method is used:
>>>
>>> BPredUnit::predictInOrder()
>>>
>>> I greped the source and built code and did not find a calling point.
>>>
>>> Thanks,
>>>
>>> --
>>> Fernando A. Endo, Post-doc
>>>
>>> INRIA Rennes-Bretagne Atlantique
>>> France
>>>
>>>
>>> 2016-11-06 21:38 GMT+01:00 Jason Lowe-Power :
>>>
>>> Hi Fernando,

 Yes, it seems like a good idea to include a TAGE predictor in gem5.

>>> Please
>>>
 make patches and post them to the reviewboard. We welcome the

>>> contribution.
>>>
 Additionally, I believe there was a recent email about a possible bug

>>> when
>>>
 updating the branch predictor state on a mis-speculation. If you're
 familiar with this code, or know of a fix for this, we would appreciate
 a
 patch. Or, if it's actually not broken, that would be great, too. It's

>>> part
>>>
 of the code that I'm not very familiar with.

 Cheers,
 Jason

 On Fri, Nov 4, 2016 at 9:46 AM Fernando Endo 
 wrote:

 Hello all,

 I'd like to know if the gem5 community would like to have a TAGE branch
 prediction in gem5.
 In my branch it seems to be working, so if you give me a positive

>>> feedback
>>>
 I may spend some spare time to rebase and test the patch over
 mainstream.

 More specifically, I took the CBP2016 winner and removed local
 prediction
 tables. This specific version is called TAGE-GSC (Global Statistical
 Corrector) and should go to src/cpu/pred/tage-gsc.hh. This file is
 functionally equivalent to the original CBP2016 winner and can be

>>> compared
>>>
 against it without modification. Then, a glue code was implemented in
 src/cpu/pred/TAGE.hh and src/cpu/pred/TAGE.cc, making tage-gsc.hh to
 work
 in gem5.

 I validated the gem5 implementation by comparing the predictor at fetch
 with a validator at commit. The prediction tables must be the same.

 Regards,

 --
 Fernando A. Endo, Post-doc

 INRIA Rennes-Bretagne Atlantique
 France
 ___
 gem5-dev mailing list
 gem5-dev@gem5.org
 http://m5sim.org/mailman/listinfo/gem5-dev
 ___
 gem5-dev mailing list
 gem5-dev@gem5.org
 http://m5sim.org/mailman/listinfo/gem5-dev

 ___
>>> gem5-dev mailing list
>>> gem5-dev@gem5.org
>>> http://m5sim.org/mailman/listinfo/gem5-dev
>>>
>>>
>>> ___
>> gem5-dev mailing list
>> gem5-dev@gem5.org
>> http://m5sim.org/mailman/listinfo/gem5-dev
>>
>
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3710: cpu: Resolve targets of predicted 'taken' conditional direct branches at decode (o3)

[Fernando Endo]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3710/#review9156
---

Ship it!


Ship It!

- Fernando Endo


On Nov. 18, 2016, 3:21 p.m., Arthur Perais wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3710/
> ---
> 
> (Updated Nov. 18, 2016, 3:21 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11707:1d085f66c4ca
> ---
> cpu: Resolve targets of predicted 'taken' conditional direct branches at 
> decode (o3)
> 
> The target of taken conditional direct branches does not 
> need to be resolved in IEW: the target can be computed at 
> decode, usually using the decoded instruction word and the PC.
> 
> The higher-than-necessary penalty is taken only on conditional
> branches that are predicted taken but miss in the BTB. Thus, 
> this is mostly inconsequential on IPC if the BTB is big/associative 
> enough (fewer capacity/conflict misses). Nonetheless, what gem5 
> simulates is not representative of how conditional branch targets 
> can be handled.
> 
> 
> Diffs
> -
> 
>   src/cpu/o3/decode_impl.hh c38fcdaa5fe5 
> 
> Diff: http://reviews.gem5.org/r/3710/diff/
> 
> 
> Testing
> ---
> 
> util/regress --modes=se
> 
> build/NULL/tests/opt/quick/se/51.memcheck/null/none/memcheck: FAILED! (Python 
> says "NameError: name 'TrafficGen' is not defined"). I'm guessing this is OK 
> as I get the same error without my patch.
> 
> 
> Thanks,
> 
> Arthur Perais
> 
>

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Cron /z/m5/regression/do-regression quick

[Cron Daemon]

* build/HSAIL_X86/tests/opt/quick/se/04.gpu/x86/linux/gpu-ruby-GPU_RfO: 
CHANGED!
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing: passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing: passed.
* build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby: 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing: passed.
 * build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing-mt: 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby: 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic: passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-simple:
 passed.
* 
build/ALPHA/tests/opt/quick/se/03.learning-gem5/alpha/linux/learning-gem5-p1-two-level:
 passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic: 
passed.* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual:
 passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing: 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual:
 passed.
* 
build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic:
 passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby: 
passed.
* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-simple:
 passed.* 
build/MIPS/tests/opt/quick/se/03.learning-gem5/mips/linux/learning-gem5-p1-two-level:
 passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing: passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic: 
passed.* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing: 
passed.
* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest: passed.
* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest-filter: passed.
* build/NULL/tests/opt/quick/se/51.memcheck/null/none/memcheck: passed.
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-dram-ctrl: passed.
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-simple-mem: 
passed.* build/NULL/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby: 
passed.
* 
build/NULL_MOESI_hammer/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_hammer:
 passed.
* 
build/NULL_MESI_Two_Level/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MESI_Two_Level:
 passed.
* 
build/NULL_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_directory:
 passed.
* 
build/NULL_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/null/none/rubytest-ruby-MOESI_CMP_token:
 passed.
* build/POWER/tests/opt/quick/se/00.hello/power/linux/simple-atomic: passed.
* build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing: passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-atomic: passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing-ruby: 
passed.
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/o3-timing: 
passed.* 
build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-timing: passed.
* build/SPARC/tests/opt/quick/se/02.insttest/sparc/linux/simple-atomic: 
passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/simple-timing: passed.
 * 
build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-simple:
 passed.
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/o3-timing-mp:
 passed.
* 
build/SPARC/tests/opt/quick/se/03.learning-gem5/sparc/linux/learning-gem5-p1-two-level:
 passed.
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp:
 passed.
* 
build/SPARC/tests/opt/quick/se/40.m5threads-test-atomic/sparc/linux/simple-timing-mp:
 passed.
* build/SPARC/tests/opt/quick/se/10.mcf/sparc/linux/simple-atomic: passed.
* build/SPARC/tests/opt/quick/se/50.vortex/sparc/linux/simple-timing: 
passed.
* build/SPARC/tests/opt/quick/se/50.vortex/sparc/linux/simple-atomic: 
passed.
* build/SPARC/tests/opt/quick/se/70.twolf/sparc/linux/simple-atomic: passed.
* build/SPARC/tests/opt/quick/se/70.twolf/sparc/linux/simple-timing: passed.
* build/X86/tests/opt/quick/se/00.hello/x86/linux/o3-timing: passed.
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing: passed.
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-atomic: passed.
* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing-ruby: 
passed.
* 
build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-simple:
 passed.
* 
build/X86/tests/opt/quick/se/03.learning-gem5/x86/linux/learning-gem5-p1-two-level:
 passed.
* build/X86/tests/opt/quick/se/10.mcf/x86/linux/simple-atomic: passed.
* build/X86/tests/opt/q