On 05/20/2016 07:50 AM, David Wohlferd wrote: > At a minimum, suddenly forcing an unexpected/unneeded memory clobber > can adversely impact the optimization of surrounding code. This can > be particularly annoying if the reason for the asm was to improve > performance. And adding a memory clobber does add a dependency of > sorts, which might cause the location of the asm to shift in an > unfortunate way. And there's always the long-shot possibility that > some weird quirk or (very) badly-written code will cause the asm to > flat out fail when used with a memory clobber. And if this change > does produce any of these problems, I feel pity for whoever has to > track it down.
OTOH, if a memory clobber does change code gen it probably changes it in a way which better fits user expectations, and perhaps it fixes a bug. That's a win, and it is far, far more important than any other consideration. Given that a basic asm statements has neither inputs nor outputs, it must have side effects to be useful. All this patch does is recognize that fact. I'm not saying your scenario won't occur, but it won't in the majority of cases. > I realize deprecation/removal is drastic. Especially since basic > asm (mostly) works as is. But fixing memory clobbers while leaving > the rest broken feels like half a solution, meaning that some day > we're going to have to fiddle with this again. Yes, we will undoubtedly have to fiddle with basic asm again. We should plan for deprecation. But I think you're close to the all-or-nothing fallacy: that because this patch doesn't solve all the problems with basic asm, it isn't worth having. Andrew.
