diff for duplicates of <20180530194554.GM7063@linux.vnet.ibm.com> diff --git a/a/1.txt b/N1/1.txt index d2fc84b..1ca5d8c 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -39,79 +39,3 @@ On Wed, May 30, 2018 at 03:08:43PM -0400, Alan Stern wrote: > > (After rereading his message a few times, I'm not sure exactly what > Linus was talking about...) - -From what I could see, real compilers and real hardware. ;-) - -> > In a perfect world, these would be the same, but it -> > appears that the world might not be perfect just now. -> > -> > My current guess is that we need to change the memory-model tool. If -> > that is the case, here are some possible resolutions: -> > -> > 1. Make herd's C-language control dependencies work the same as its -> > assembly language, so that they extend beyond the end of the -> > "if" statement. I believe that this would make Roman's case -> > work, but it could claim that other situations are safe that -> > are actually problematic due to compiler optimizations. -> > -> > The fact that the model currently handles only READ_ONCE() -> > and WRITE_ONCE() and not unmarked reads and writes make this -> > option more attractive than it otherwise be, compilers not -> > being allowed to reorder volatile accesses, but we are likely -> > to introduce unmarked accesses sometime in the future. -> -> Preserving the order of volatile accesses isn't sufficient. The -> compiler is still allowed to translate -> -> r1 = READ_ONCE(x); -> if (r1) { -> ... -> } -> WRITE_ONCE(y, r2); -> -> into something resembling -> -> r1 = READ_ONCE(x); -> WRITE_ONCE(y, r2); -> if (r1) { -> ... -> } -> -> (provided the "..." part doesn't contain any volatile accesses, -> barriers, or anything affecting r2), which would destroy any run-time -> control dependency. The CPU could then execute the write before the -> read. - -True, but almost all current litmus tests do have at least one volatile -access in their "if" statements. I am guessing that this has the same -memory-model tooling issues as #2 below, but I am as usual happy to be -proven wrong. ;-) - -> > 2. Like #1 above, but only if something in one of the "if"'s -> > branches would prevent the compiler from reordering -> > (smp_mb(), synchronize_rcu(), value-returning non-relaxed -> > RMW atomic, ...). Easy for me to say, but I am guessing -> > that much violence would be needed to the tooling to make -> > this work. ;-) -> -> This would be my preference. But I'm afraid it isn't practical at the -> moment. - -I bet that some combination of scripting and smallish modifications to -tooling could make it happen in reasonably short term. Might be more -difficult to make something more future-proof, though, agreed. - -> > If I understand Alan correctly, there is not an obvious way to make -> > this change within the confines of the memory model's .bell and .cat -> > files. -> -> No way at all. It would require significant changes to herd's internal -> workings and its external interface -- my original point. - -I was afraid of that. ;-) - -Though truth be told, I was expecting an issue like this to crop up -sooner rather than later, so I was actually getting a bit nervous -about the fact that it had not yet shown itself... - - Thanx, Paul diff --git a/a/content_digest b/N1/content_digest index a6afef0..fde0d70 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -60,82 +60,6 @@ "> real hardware.\n" "> \n" "> (After rereading his message a few times, I'm not sure exactly what \n" - "> Linus was talking about...)\n" - "\n" - "From what I could see, real compilers and real hardware. ;-)\n" - "\n" - "> > In a perfect world, these would be the same, but it\n" - "> > appears that the world might not be perfect just now.\n" - "> > \n" - "> > My current guess is that we need to change the memory-model tool. If\n" - "> > that is the case, here are some possible resolutions:\n" - "> > \n" - "> > 1.\tMake herd's C-language control dependencies work the same as its\n" - "> > \tassembly language, so that they extend beyond the end of the\n" - "> > \t\"if\" statement. I believe that this would make Roman's case\n" - "> > \twork, but it could claim that other situations are safe that\n" - "> > \tare actually problematic due to compiler optimizations.\n" - "> > \n" - "> > \tThe fact that the model currently handles only READ_ONCE()\n" - "> > \tand WRITE_ONCE() and not unmarked reads and writes make this\n" - "> > \toption more attractive than it otherwise be, compilers not\n" - "> > \tbeing allowed to reorder volatile accesses, but we are likely\n" - "> > \tto introduce unmarked accesses sometime in the future.\n" - "> \n" - "> Preserving the order of volatile accesses isn't sufficient. The\n" - "> compiler is still allowed to translate\n" - "> \n" - "> \tr1 = READ_ONCE(x);\n" - "> \tif (r1) {\n" - "> \t\t...\n" - "> \t}\n" - "> \tWRITE_ONCE(y, r2);\n" - "> \n" - "> into something resembling\n" - "> \n" - "> \tr1 = READ_ONCE(x);\n" - "> \tWRITE_ONCE(y, r2);\n" - "> \tif (r1) {\n" - "> \t\t...\n" - "> \t}\n" - "> \n" - "> (provided the \"...\" part doesn't contain any volatile accesses,\n" - "> barriers, or anything affecting r2), which would destroy any run-time\n" - "> control dependency. The CPU could then execute the write before the\n" - "> read.\n" - "\n" - "True, but almost all current litmus tests do have at least one volatile\n" - "access in their \"if\" statements. I am guessing that this has the same\n" - "memory-model tooling issues as #2 below, but I am as usual happy to be\n" - "proven wrong. ;-)\n" - "\n" - "> > 2.\tLike #1 above, but only if something in one of the \"if\"'s\n" - "> > \tbranches would prevent the compiler from reordering\n" - "> > \t(smp_mb(), synchronize_rcu(), value-returning non-relaxed\n" - "> > \tRMW atomic, ...). Easy for me to say, but I am guessing\n" - "> > \tthat much violence would be needed to the tooling to make\n" - "> > \tthis work. ;-)\n" - "> \n" - "> This would be my preference. But I'm afraid it isn't practical at the \n" - "> moment.\n" - "\n" - "I bet that some combination of scripting and smallish modifications to\n" - "tooling could make it happen in reasonably short term. Might be more\n" - "difficult to make something more future-proof, though, agreed.\n" - "\n" - "> > If I understand Alan correctly, there is not an obvious way to make\n" - "> > this change within the confines of the memory model's .bell and .cat\n" - "> > files.\n" - "> \n" - "> No way at all. It would require significant changes to herd's internal \n" - "> workings and its external interface -- my original point.\n" - "\n" - "I was afraid of that. ;-)\n" - "\n" - "Though truth be told, I was expecting an issue like this to crop up\n" - "sooner rather than later, so I was actually getting a bit nervous\n" - "about the fact that it had not yet shown itself...\n" - "\n" - "\t\t\t\t\t\t\tThanx, Paul" + > Linus was talking about...) -83cf204991a57ecad88d51e14b9488f5d902233af7a5ea7984dabbdbf95db36a +a56d67dd33ae1475eabdd857277f6aac5714efcf940bf5e3c9d7e0b4ec071776
diff --git a/a/1.txt b/N2/1.txt index d2fc84b..aa68545 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -40,7 +40,7 @@ On Wed, May 30, 2018 at 03:08:43PM -0400, Alan Stern wrote: > (After rereading his message a few times, I'm not sure exactly what > Linus was talking about...) -From what I could see, real compilers and real hardware. ;-) +>From what I could see, real compilers and real hardware. ;-) > > In a perfect world, these would be the same, but it > > appears that the world might not be perfect just now. diff --git a/a/content_digest b/N2/content_digest index a6afef0..eaee9de 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -62,7 +62,7 @@ "> (After rereading his message a few times, I'm not sure exactly what \n" "> Linus was talking about...)\n" "\n" - "From what I could see, real compilers and real hardware. ;-)\n" + ">From what I could see, real compilers and real hardware. ;-)\n" "\n" "> > In a perfect world, these would be the same, but it\n" "> > appears that the world might not be perfect just now.\n" @@ -138,4 +138,4 @@ "\n" "\t\t\t\t\t\t\tThanx, Paul" -83cf204991a57ecad88d51e14b9488f5d902233af7a5ea7984dabbdbf95db36a +7d1c270c829908219503e04ec9568aad51a510abf7769a5d9577c865ed523098
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.