On 09/18/14 08:32, Richard Biener wrote:
On September 18, 2014 3:36:24 PM CEST, Jeff Law <l...@redhat.com>
wrote:
On 09/18/14 05:19, Yury Gribov wrote:
Would that modifier mean that the inline asm is
unconditionally
reading
resp. writing that memory? "m"/"=m" right now is always about
might read or might write, not must.
Yes, that's what I had in mind. Many inline asms (at least in
kernel)
do
read memory region unconditionally.
That's precisely what I'd expect such a modifier to mean. Right
now memory modifiers are strictly "may" but I can see a use case
for "must".
I think the question is will the kernel or glibc folks use that
new capability and if so, do we get a significant improvement in
the amount
of checking we can do. So I think both those groups need to be
looped into this conversation.
From an implementation standpoint, are you thinking a different
modifier (my first choice)? That wouldn't allow us to say
something like the first X bytes of this memory region are written
and the remaining Y bytes may be written, but I suspect that's not
a use case we're likely to care about.
It would also enable us to do more DSE as the asm stmt is then known
to kill a specific part of memory. Maybe we even want to constrain
the effective type of the memory accesses so we can do TBAA against
inline asms?
Yea, but I suspect there aren't that many opportunities to do DSE that
are enabled by seeing the the must-write in an ASM.
Then again, one might argue that even if they aren't common, if they do
occur, they're important as (in theory) folks shouldn't be using ASMs if
the code isn't hot.
jeff
