Re: [m5-dev] Review Request: O3: Tighten memory order violation checking to 16 bytes.

2011-04-23 Thread Gabe Black 
Never mind. The test was easy to write.

Gabe

On 04/23/11 13:55, Gabe Black wrote:
> I have a plan for how to fix this which won't be that difficult, but
> since it's going to be near the heart of all the x86 instruction
> machinery I'd like to be able to test it. I could put together a
> specialized test case which has a malformed instruction that should hit
> this even in the simple CPUs, but it would be easier if you can just
> give me a command line. If it takes a long time to run or I'd need extra
> patches then don't worry about it.
>
> Gabe
>
> On 04/22/11 10:25, Gabe Black wrote:
>> It looks like this patch was committed, but it didn't have anything to
>> do with the assert. It just happened to change whether or not that
>> assert was hit. I'll take a look at it sometime soon.
>>
>> Gabe
>>
>> On 04/22/11 10:04, nathan binkert wrote:
>>> Did this ever get committed?  I'm running into this bug with 20.parser.
>>>
>>>   Nate
>>>
>>> On Wed, Mar 30, 2011 at 8:46 AM, Ali Saidi  wrote:
>>>
This is an automatically generated e-mail. To reply, visit:
 http://reviews.m5sim.org/r/520/

 I think the updated patch addresses all of your issues Gabe. I tested it 
 with an opt binary and one problem jumped out in x86 for 20.parser an 
 assert:
 m5.opt: build/X86_SE/arch/x86/emulenv.cc:49: void 
 X86ISA::EmulEnv::doModRM(const X86ISA::ExtMachInst&): Assertion 
 `machInst.modRM.mod != 3' failed.

 It looks like the assert shouldn't be there and is hit during some miss 
 speculation.


 - Ali

 On March 30th, 2011, 8:41 a.m., Ali Saidi wrote:
   Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
 Nathan Binkert.
 By Ali Saidi.

 *Updated 2011-03-30 08:41:48*
 Description

 O3: Tighten memory order violation checking to 16 bytes.

 The comment in the code suggests that the checking granularity should be 16
 bytes, however in reality the shift by 8 is 256 bytes which seems much
 larger than required.

   Diffs

- src/cpu/base_dyn_inst.hh (d54b7775a6b0)
- src/cpu/o3/O3CPU.py (d54b7775a6b0)
- src/cpu/o3/lsq_unit.hh (d54b7775a6b0)
- src/cpu/o3/lsq_unit_impl.hh (d54b7775a6b0)

 View Diff 

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

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

Re: [m5-dev] Review Request: O3: Tighten memory order violation checking to 16 bytes.

2011-04-23 Thread Gabe Black 
I have a plan for how to fix this which won't be that difficult, but
since it's going to be near the heart of all the x86 instruction
machinery I'd like to be able to test it. I could put together a
specialized test case which has a malformed instruction that should hit
this even in the simple CPUs, but it would be easier if you can just
give me a command line. If it takes a long time to run or I'd need extra
patches then don't worry about it.

Gabe

On 04/22/11 10:25, Gabe Black wrote:
> It looks like this patch was committed, but it didn't have anything to
> do with the assert. It just happened to change whether or not that
> assert was hit. I'll take a look at it sometime soon.
>
> Gabe
>
> On 04/22/11 10:04, nathan binkert wrote:
>> Did this ever get committed?  I'm running into this bug with 20.parser.
>>
>>   Nate
>>
>> On Wed, Mar 30, 2011 at 8:46 AM, Ali Saidi  wrote:
>>
>>>This is an automatically generated e-mail. To reply, visit:
>>> http://reviews.m5sim.org/r/520/
>>>
>>> I think the updated patch addresses all of your issues Gabe. I tested it 
>>> with an opt binary and one problem jumped out in x86 for 20.parser an 
>>> assert:
>>> m5.opt: build/X86_SE/arch/x86/emulenv.cc:49: void 
>>> X86ISA::EmulEnv::doModRM(const X86ISA::ExtMachInst&): Assertion 
>>> `machInst.modRM.mod != 3' failed.
>>>
>>> It looks like the assert shouldn't be there and is hit during some miss 
>>> speculation.
>>>
>>>
>>> - Ali
>>>
>>> On March 30th, 2011, 8:41 a.m., Ali Saidi wrote:
>>>   Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
>>> Nathan Binkert.
>>> By Ali Saidi.
>>>
>>> *Updated 2011-03-30 08:41:48*
>>> Description
>>>
>>> O3: Tighten memory order violation checking to 16 bytes.
>>>
>>> The comment in the code suggests that the checking granularity should be 16
>>> bytes, however in reality the shift by 8 is 256 bytes which seems much
>>> larger than required.
>>>
>>>   Diffs
>>>
>>>- src/cpu/base_dyn_inst.hh (d54b7775a6b0)
>>>- src/cpu/o3/O3CPU.py (d54b7775a6b0)
>>>- src/cpu/o3/lsq_unit.hh (d54b7775a6b0)
>>>- src/cpu/o3/lsq_unit_impl.hh (d54b7775a6b0)
>>>
>>> View Diff 
>>>
>> ___
>> m5-dev mailing list
>> m5-dev@m5sim.org
>> http://m5sim.org/mailman/listinfo/m5-dev
> ___
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev

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

Re: [m5-dev] Review Request: O3: Tighten memory order violation checking to 16 bytes.

2011-04-22 Thread Gabe Black 
It looks like this patch was committed, but it didn't have anything to
do with the assert. It just happened to change whether or not that
assert was hit. I'll take a look at it sometime soon.

Gabe

On 04/22/11 10:04, nathan binkert wrote:
> Did this ever get committed?  I'm running into this bug with 20.parser.
>
>   Nate
>
> On Wed, Mar 30, 2011 at 8:46 AM, Ali Saidi  wrote:
>
>>This is an automatically generated e-mail. To reply, visit:
>> http://reviews.m5sim.org/r/520/
>>
>> I think the updated patch addresses all of your issues Gabe. I tested it 
>> with an opt binary and one problem jumped out in x86 for 20.parser an assert:
>> m5.opt: build/X86_SE/arch/x86/emulenv.cc:49: void 
>> X86ISA::EmulEnv::doModRM(const X86ISA::ExtMachInst&): Assertion 
>> `machInst.modRM.mod != 3' failed.
>>
>> It looks like the assert shouldn't be there and is hit during some miss 
>> speculation.
>>
>>
>> - Ali
>>
>> On March 30th, 2011, 8:41 a.m., Ali Saidi wrote:
>>   Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
>> Nathan Binkert.
>> By Ali Saidi.
>>
>> *Updated 2011-03-30 08:41:48*
>> Description
>>
>> O3: Tighten memory order violation checking to 16 bytes.
>>
>> The comment in the code suggests that the checking granularity should be 16
>> bytes, however in reality the shift by 8 is 256 bytes which seems much
>> larger than required.
>>
>>   Diffs
>>
>>- src/cpu/base_dyn_inst.hh (d54b7775a6b0)
>>- src/cpu/o3/O3CPU.py (d54b7775a6b0)
>>- src/cpu/o3/lsq_unit.hh (d54b7775a6b0)
>>- src/cpu/o3/lsq_unit_impl.hh (d54b7775a6b0)
>>
>> View Diff 
>>
> ___
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev

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

Re: [m5-dev] Review Request: O3: Tighten memory order violation checking to 16 bytes.

2011-04-22 Thread nathan binkert 
Did this ever get committed?  I'm running into this bug with 20.parser.

  Nate

On Wed, Mar 30, 2011 at 8:46 AM, Ali Saidi  wrote:

>This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/520/
>
> I think the updated patch addresses all of your issues Gabe. I tested it with 
> an opt binary and one problem jumped out in x86 for 20.parser an assert:
> m5.opt: build/X86_SE/arch/x86/emulenv.cc:49: void 
> X86ISA::EmulEnv::doModRM(const X86ISA::ExtMachInst&): Assertion 
> `machInst.modRM.mod != 3' failed.
>
> It looks like the assert shouldn't be there and is hit during some miss 
> speculation.
>
>
> - Ali
>
> On March 30th, 2011, 8:41 a.m., Ali Saidi wrote:
>   Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and
> Nathan Binkert.
> By Ali Saidi.
>
> *Updated 2011-03-30 08:41:48*
> Description
>
> O3: Tighten memory order violation checking to 16 bytes.
>
> The comment in the code suggests that the checking granularity should be 16
> bytes, however in reality the shift by 8 is 256 bytes which seems much
> larger than required.
>
>   Diffs
>
>- src/cpu/base_dyn_inst.hh (d54b7775a6b0)
>- src/cpu/o3/O3CPU.py (d54b7775a6b0)
>- src/cpu/o3/lsq_unit.hh (d54b7775a6b0)
>- src/cpu/o3/lsq_unit_impl.hh (d54b7775a6b0)
>
> View Diff 
>
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: O3: Tighten memory order violation checking to 16 bytes.

2011-03-30 Thread Ali Saidi 


> On 2011-03-30 09:08:07, Gabe Black wrote:
> > src/cpu/base_dyn_inst.hh, line 246
> > 
> >
> > This comment is inaccurate. It's really the largest address that's part 
> > of the request, which is the effective address plus the size and then minus 
> > one. Also, this feels like a temporary variable promoted to too large of a 
> > scope and/or permanence. "size" seems like it would be more generally 
> > useful, it would be more immediately obvious what it is, and you can go 
> > from one to the other easily like you are elsewhere in this change.

I'll change it to size.


- Ali


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/520/#review1034
---


On 2011-03-30 08:41:48, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/520/
> ---
> 
> (Updated 2011-03-30 08:41:48)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> O3: Tighten memory order violation checking to 16 bytes.
> 
> The comment in the code suggests that the checking granularity should be 16
> bytes, however in reality the shift by 8 is 256 bytes which seems much
> larger than required.
> 
> 
> Diffs
> -
> 
>   src/cpu/base_dyn_inst.hh d54b7775a6b0 
>   src/cpu/o3/O3CPU.py d54b7775a6b0 
>   src/cpu/o3/lsq_unit.hh d54b7775a6b0 
>   src/cpu/o3/lsq_unit_impl.hh d54b7775a6b0 
> 
> Diff: http://reviews.m5sim.org/r/520/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: O3: Tighten memory order violation checking to 16 bytes.

2011-03-30 Thread Gabe Black 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/520/#review1034
---


I can't verify 100% that the code in your new function is correct, but I don't 
see anything obviously wrong. I really like that you consolidated the same code 
in two places down to the one. There's one issue which is pointed out below.


src/cpu/base_dyn_inst.hh


This comment is inaccurate. It's really the largest address that's part of 
the request, which is the effective address plus the size and then minus one. 
Also, this feels like a temporary variable promoted to too large of a scope 
and/or permanence. "size" seems like it would be more generally useful, it 
would be more immediately obvious what it is, and you can go from one to the 
other easily like you are elsewhere in this change.


- Gabe


On 2011-03-30 08:41:48, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/520/
> ---
> 
> (Updated 2011-03-30 08:41:48)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> O3: Tighten memory order violation checking to 16 bytes.
> 
> The comment in the code suggests that the checking granularity should be 16
> bytes, however in reality the shift by 8 is 256 bytes which seems much
> larger than required.
> 
> 
> Diffs
> -
> 
>   src/cpu/base_dyn_inst.hh d54b7775a6b0 
>   src/cpu/o3/O3CPU.py d54b7775a6b0 
>   src/cpu/o3/lsq_unit.hh d54b7775a6b0 
>   src/cpu/o3/lsq_unit_impl.hh d54b7775a6b0 
> 
> Diff: http://reviews.m5sim.org/r/520/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: O3: Tighten memory order violation checking to 16 bytes.

2011-03-30 Thread Ali Saidi 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/520/#review1033
---


I think the updated patch addresses all of your issues Gabe. I tested it with 
an opt binary and one problem jumped out in x86 for 20.parser an assert: 
m5.opt: build/X86_SE/arch/x86/emulenv.cc:49: void 
X86ISA::EmulEnv::doModRM(const X86ISA::ExtMachInst&): Assertion 
`machInst.modRM.mod != 3' failed.

It looks like the assert shouldn't be there and is hit during some miss 
speculation. 

- Ali


On 2011-03-30 08:41:48, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/520/
> ---
> 
> (Updated 2011-03-30 08:41:48)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> O3: Tighten memory order violation checking to 16 bytes.
> 
> The comment in the code suggests that the checking granularity should be 16
> bytes, however in reality the shift by 8 is 256 bytes which seems much
> larger than required.
> 
> 
> Diffs
> -
> 
>   src/cpu/base_dyn_inst.hh d54b7775a6b0 
>   src/cpu/o3/O3CPU.py d54b7775a6b0 
>   src/cpu/o3/lsq_unit.hh d54b7775a6b0 
>   src/cpu/o3/lsq_unit_impl.hh d54b7775a6b0 
> 
> Diff: http://reviews.m5sim.org/r/520/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: O3: Tighten memory order violation checking to 16 bytes.

2011-03-30 Thread Ali Saidi 

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

(Updated 2011-03-30 08:41:48.614227)


Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

O3: Tighten memory order violation checking to 16 bytes.

The comment in the code suggests that the checking granularity should be 16
bytes, however in reality the shift by 8 is 256 bytes which seems much
larger than required.


Diffs (updated)
-

  src/cpu/base_dyn_inst.hh d54b7775a6b0 
  src/cpu/o3/O3CPU.py d54b7775a6b0 
  src/cpu/o3/lsq_unit.hh d54b7775a6b0 
  src/cpu/o3/lsq_unit_impl.hh d54b7775a6b0 

Diff: http://reviews.m5sim.org/r/520/diff


Testing
---


Thanks,

Ali

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

Re: [m5-dev] Review Request: O3: Tighten memory order violation checking to 16 bytes.

2011-03-18 Thread Gabe Black 


> On 2011-02-27 21:41:48, Gabe Black wrote:
> > Should we put an assert in there to make sure no access is bigger than 16 
> > bytes? Also what about unaligned accesses? I think those will be split on 
> > cache block boundaries which may be bigger or smaller than 16 bytes. We 
> > might have an access that spans from one 16 byte chunk to the next. These 
> > aren't really problems with this change, but it might make them easier to 
> > hit.
> > 
> > I'm assuming this had some effect on the regressions. Did things generally 
> > go faster, slower, etc.?
> 
> Ali Saidi wrote:
> Not major changes, but things usually sped up a little bit.
> 
> Ali Saidi wrote:
> Actually it is quite a change for some benchmarks, it's just not uniform. 
> High of 17%, low of 0%, average of about 5%. So I think we need to fix it and 
> if it exposes other bugs, so be it, but the regression tests all complete 
> successfully. 
> 
> alpha
> --
> eon: 17%
> twolf: 15%
> vortex: 5%
> gzip 0%
> linux: 0%
> bzip2: 3%
> perlbmk: 2%
> 
> 
> parc
> 
> gzip: 3%
> 
> x86
> 
> mcf: 17%
> parser: 4%
> twolf: 2%
> gzip: 2%
> 
> arm
> --
> gzip: 7%
> mcf: 2%
> eon: 13%
> twolf: 3%
> parser: 3%
> vortex: 6%
> perlbmk: 
> bzip2:
> linux: 1%
> 
>

Yes, we shouldn't delay fixing this bug for the sake of the other ones that 
might be in there too. We should still add an assert if possible, though, so we 
catch those bugs if they happen.


- Gabe


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/520/#review915
---


On 2011-02-27 18:52:51, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/520/
> ---
> 
> (Updated 2011-02-27 18:52:51)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> O3: Tighten memory order violation checking to 16 bytes.
> 
> The comment in the code suggests that the checking granularity should be 16
> bytes, however in reality the shift by 8 is 256 bytes which seems much
> larger than required.
> 
> 
> Diffs
> -
> 
>   src/cpu/o3/lsq_unit_impl.hh 9dc17725f795 
> 
> Diff: http://reviews.m5sim.org/r/520/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: O3: Tighten memory order violation checking to 16 bytes.

2011-03-18 Thread Ali Saidi 


> On 2011-02-27 21:41:48, Gabe Black wrote:
> > Should we put an assert in there to make sure no access is bigger than 16 
> > bytes? Also what about unaligned accesses? I think those will be split on 
> > cache block boundaries which may be bigger or smaller than 16 bytes. We 
> > might have an access that spans from one 16 byte chunk to the next. These 
> > aren't really problems with this change, but it might make them easier to 
> > hit.
> > 
> > I'm assuming this had some effect on the regressions. Did things generally 
> > go faster, slower, etc.?
> 
> Ali Saidi wrote:
> Not major changes, but things usually sped up a little bit.

Actually it is quite a change for some benchmarks, it's just not uniform. High 
of 17%, low of 0%, average of about 5%. So I think we need to fix it and if it 
exposes other bugs, so be it, but the regression tests all complete 
successfully. 

alpha
--
eon: 17%
twolf: 15%
vortex: 5%
gzip 0%
linux: 0%
bzip2: 3%
perlbmk: 2%


parc

gzip: 3%

x86

mcf: 17%
parser: 4%
twolf: 2%
gzip: 2%

arm
--
gzip: 7%
mcf: 2%
eon: 13%
twolf: 3%
parser: 3%
vortex: 6%
perlbmk: 
bzip2:
linux: 1%


- Ali


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/520/#review915
---


On 2011-02-27 18:52:51, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/520/
> ---
> 
> (Updated 2011-02-27 18:52:51)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> O3: Tighten memory order violation checking to 16 bytes.
> 
> The comment in the code suggests that the checking granularity should be 16
> bytes, however in reality the shift by 8 is 256 bytes which seems much
> larger than required.
> 
> 
> Diffs
> -
> 
>   src/cpu/o3/lsq_unit_impl.hh 9dc17725f795 
> 
> Diff: http://reviews.m5sim.org/r/520/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: O3: Tighten memory order violation checking to 16 bytes.

2011-03-17 Thread Ali Saidi 


> On 2011-02-27 21:41:48, Gabe Black wrote:
> > Should we put an assert in there to make sure no access is bigger than 16 
> > bytes? Also what about unaligned accesses? I think those will be split on 
> > cache block boundaries which may be bigger or smaller than 16 bytes. We 
> > might have an access that spans from one 16 byte chunk to the next. These 
> > aren't really problems with this change, but it might make them easier to 
> > hit.
> > 
> > I'm assuming this had some effect on the regressions. Did things generally 
> > go faster, slower, etc.?

Not major changes, but things usually sped up a little bit.


- Ali


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/520/#review915
---


On 2011-02-27 18:52:51, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/520/
> ---
> 
> (Updated 2011-02-27 18:52:51)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> O3: Tighten memory order violation checking to 16 bytes.
> 
> The comment in the code suggests that the checking granularity should be 16
> bytes, however in reality the shift by 8 is 256 bytes which seems much
> larger than required.
> 
> 
> Diffs
> -
> 
>   src/cpu/o3/lsq_unit_impl.hh 9dc17725f795 
> 
> Diff: http://reviews.m5sim.org/r/520/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: O3: Tighten memory order violation checking to 16 bytes.

2011-02-27 Thread Gabe Black 

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/520/#review915
---


Should we put an assert in there to make sure no access is bigger than 16 
bytes? Also what about unaligned accesses? I think those will be split on cache 
block boundaries which may be bigger or smaller than 16 bytes. We might have an 
access that spans from one 16 byte chunk to the next. These aren't really 
problems with this change, but it might make them easier to hit.

I'm assuming this had some effect on the regressions. Did things generally go 
faster, slower, etc.?

- Gabe


On 2011-02-27 18:52:51, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/520/
> ---
> 
> (Updated 2011-02-27 18:52:51)
> 
> 
> Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and 
> Nathan Binkert.
> 
> 
> Summary
> ---
> 
> O3: Tighten memory order violation checking to 16 bytes.
> 
> The comment in the code suggests that the checking granularity should be 16
> bytes, however in reality the shift by 8 is 256 bytes which seems much
> larger than required.
> 
> 
> Diffs
> -
> 
>   src/cpu/o3/lsq_unit_impl.hh 9dc17725f795 
> 
> Diff: http://reviews.m5sim.org/r/520/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

[m5-dev] Review Request: O3: Tighten memory order violation checking to 16 bytes.

2011-02-27 Thread Ali Saidi 

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

Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan 
Binkert.


Summary
---

O3: Tighten memory order violation checking to 16 bytes.

The comment in the code suggests that the checking granularity should be 16
bytes, however in reality the shift by 8 is 256 bytes which seems much
larger than required.


Diffs
-

  src/cpu/o3/lsq_unit_impl.hh 9dc17725f795 

Diff: http://reviews.m5sim.org/r/520/diff


Testing
---


Thanks,

Ali

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