On Sun, 22 May 2016, Andrew Haley wrote: > 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.
I think adding memory clobbers is worth having. I also think that deprecating basic asms would be a good thing, so can we please add a new warning for that? "warning: basic asms are deprecated" Richard.
