Will support be added to the caches? Can you perhaps provide some more hints in the patch description. At the moment it seems we are just bloating the packet.

src/mem/packet.hh (Diff revision 1)

2010, 2015 I suppose? Or has this been ongoing for five years?

Show all issues

src/mem/packet.cc (Diff revision 1)

2010, 2013? How does it match with the 2015 in the request?

Show all issues

src/mem/request.hh (Diff revision 1)

Same as above

Show all issues

src/mem/request.hh (Diff revision 1)

I do not understand this change. It seems we have enough flag bits to spare, do we not?

Show all issues

1. Tony Gutierrez May 14, 2015, 4:07 p.m. (May 14, 2015, 4:07 p.m.)

   By my count we have 27 bits used, we're adding 2, so that leaves 3 so it can't hurt.

I am also curious, how these will be used both inside the memory subsystem and at the interface layer.  Right now.. the duplication between flags and request types seems somewhat erm.. duplicate :)

src/mem/request.hh (Diff revision 2)

Why do we have new request types and new flags?  To me, you'd do only either?  So only mark loads with acquire and stores with release, no?

Show all issues

1. Marc Orr July 22, 2015, 12:12 p.m. (July 22, 2015, 12:12 p.m.)

   Our patch is similar to some of the duplication that occurs with other request types (e.g., swapreq/swapresp, and corresponding flags). More importantly, it might actually make sense to tag a request as both acquire and release (e.g., an RMW tagged memory_order_seq_cst).

src/mem/request.hh (Diff revision 2)

Boolean OR of the flags could be faster.

Show all issues

1. Marc Orr July 22, 2015, 12:12 p.m. (July 22, 2015, 12:12 p.m.)

   I don't follow exactly what you're asking for. Also, I don't think that this specific boolean expression has any impact on simulation performance.

2. Marc Orr July 23, 2015, 2:12 p.m. (July 23, 2015, 2:12 p.m.)

   Actually, now I see what you meant... We've updated this line to:
   
   return _flags.isSet(RELEASE | ACQUIRE);

I am also curious how these

Ship It!