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? Richard. >jeff
