[Bug tree-optimization/15089] [3.4/3.5 Regression] [tree-ssa] local register variable with a specified register is bad

["nico at cam dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Additional Comments From nico at cam dot org  2004-06-23 19:15 -------
Subject: Re:  [3.4/3.5 Regression] [tree-ssa]
 local register variable with a specified register is bad

> Therefore, closing this as INVALID.

I beg to disagree here.

Let's analyse the quoted manual:

   Local register variables in specific registers do not reserve the
   registers.  The compiler's data flow analysis is capable of
   determining where the specified registers contain live values,
   and where they are available for other uses.

This is perfectly sensible, although the current behavior doesn't 
correspond to this, ence this bug report.  The inline asm constitute
a precise point of use which is not respected.

   Stores into local register variables may be deleted when they appear
   to be dead according to dataflow analysis.

This is also perfectly fine, but that's not the case here since the
misassigned register is actually defined to be an input operand to
the inline assembly.  It therefore can't be dead.

   References to local register variables may be deleted or moved
   or simplified.

I still don't see how this sentence could mean "any other register can
be used", otherwise this feature would be completely non sense since no
register specification could ever be relied upon which is completely 
useless.  When the manual says "References to local register variables
may be deleted or moved or simplified", that means the "reference" can be
reordered or discarded with regards to other operations which is again 
perfectly fine, but that doesn't mean the compiler may decide to use
another register for the actual reference at all.

> When __l is used in the asm, the writer of the bugzilla report expects
> to see register "r0". 

Indeed!  That's the expected result of the feature.

> However, the value happens to be hanging around
> in a different register so GCC uses that other register instead of
> "r0".  Similarly for uses of __i.   The behavior of the compiler is
> precisely what I would expect."

This is of course the expected behavior when there is _no_ register 
specification for a given variable, which is absolutely not the case
here.  And yet the value happens to be defined by a constant right
before being used as follows:

                l = 100;
                {
                        register unsigned long long __l asm("r0") = l;
                        register unsigned long long __r asm("r2");
                        asm ( "..." _ "=r" (__r) : "r" (__l) );
                        l = __r;
                }

So there is no reason gcc would have used another register than the one
we asked it to, especially since the original l value has no life passed
the assignment to __l.  And incidentally, when the proposed patch for this 
bug is applied then that's exactly what happens.

Now let's suppose we rework the test case a bit so __l becomes an output as
well as an input to the inline asm, and that both l and __l are referenced
after the inline asm.  Then gcc doesn't have the choice to copy the value of
l into a separate register.  Even in this case the selected register doesn't
respect the register specification, even if that specification is changed to
a completely unused register like, say, r8 instead of r0.

And to further justify the proposed patch: all this is dependent on the 
presence of a surrounding loop.  If the loop is removed from the code,
it's then impossible to make the test case fail.

I'm therefore asking for this bug to be reopened and the proposed fix 
applied.  The reasons for marking this bug as invalid, are, IMHO, themselves 
invalid.  This is a documented feature that has always worked perfectly fine 
in the past, and which has existing bodies of code relying on the documented 
behavior for legitimate purposes.

Thank you.


Nicolas



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15089