Re: Deprecating basic asm in a function - What now?

[Andrew Haley <aph at redhat dot com>]

Hi,

On 20/06/16 19:01, Michael Matz wrote:

> On Mon, 20 Jun 2016, Andrew Haley wrote:
> 
>> On 20/06/16 18:36, Michael Matz wrote:
>>> I see zero gain by deprecating them and only churn.  What would be the 
>>> advantage again?
>>
>> Correctness.
> 
> As said in the various threads about basic asms, all correctness 
> problems can be solved by making GCC more conservative in handling them 
> (or better said: not making it less conservative).

Well, yes.  That's exactly why we've agreed to change basic asms to
make them clobber memory, i.e. to make GCC more conservative.

> If you talk about cases where basic asms diddle registers expecting GCC to 
> have placed e.g. local variables into specific ones (without using local 
> reg vars, or extended asm) I won't believe any claims ...
> 
>> It is very likely that many of these basic asms are not
>> robust
> 
> ... of them being very likely without proof.  They will have stopped
> working with every change in compilation options or compiler
> version.  In contrast I think those that did survive a couple years
> in software very likely _are_ correct, under the then documented (or
> implicit) assumptions.  Those usually are: clobbers and uses memory,
> processor state and fixed registers.

Well, maybe.  It's also fairly likely that many work by accident.  IMO
this is more of a statement of hope than any kind of reasonable
expectation.

>> in the face of compiler changes because they don't declare their 
>> dependencies and therefore work only by accident.
> 
> Then the compiler better won't change into less conservative
> handling of basic asms.

Repeat, repeat: the change being made is to make gcc MORE
conservative.

> You see, the experiment shows that there's a gazillion uses of basic
> asms out there.  Deprecating them means that each and every one of
> them (for us alone that's 540 something, including testsuite and
> boehm) has to be changed from asm("body") into asm("body" : : :
> "memory") (give and take some syntax for also clobbering flags).
> Alternatively rewrite the body to actually make use of extended asm.
> I guarantee you that a non-trivial percentage will be wrong _then_
> while they work fine now.  Even if it weren't so it still would be
> silly if GCC simply could regard the former as the latter
> internally.

That's what we're doing.

Andrew.