Re: Inlining bug on MIPS - both 2.95.3 and 3.0 branches

[Geoff Keating <geoffk at geoffk dot org>]

Daniel Jacobowitz <dmj+@andrew.cmu.edu> writes:

> The problem seems to be that we lift a constant term out of a loop into a
> spare register.  Of course, __builtin_constant_p is still true for it, so in
> the original case we chose to use an inline function which required that
> argument to be constant.  We inline the function using the scratch register
> instead of the constant, and we lose.
> 
> The inline function seems to me to be doing something dodgy - it specifies
> the operand with the constraint "ir", implying that a register would be
> acceptable.  We're lying to the compiler, so it's not that startling that it
> bites us.  On the other hand, there's no need to waste a register on this,
> so I'm not sure why the constant gets stored in a temporary.
> 
> Is the invalid result a compiler bug?  I'd say that there is at least a
> small optimization bug here, but the "ir" constraint might mean that the
> compiler's doing everything as best it can.  There doesn't seem to be a way
> to use an inline function safely and specify a constant constraint on one
> argument to the function - does this need to be a macro?

If an asm statement specifies "ir", it will get an immediate or a register
depending on the whim of the compiler.  

I expect that what happened is that the asm statement had a register
for that argument, reload saw that the constraint matched, and
so no further processing was done.  If the constraint was "i",
reload would see that the constraint did not match and continue
processing, and one of the things it'd try is to replace the register
with its constant value.

-- 
- Geoffrey Keating <geoffk@geoffk.org>