[RFC] Add asm constraint modifier to mark strict memory accesses

[Jeff Law]

On 09/18/14 08:32, Richard Biener wrote:
> On September 18, 2014 3:36:24 PM CEST, Jeff Law <law@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