Re: i386.md bug + fix

[Alasdair Baird <alasdair at wildcat dot demon dot co dot uk>]

The strlensi pattern in i386.md is still well and truly
screwed due to a missing USE on an implicitly used register
within the strlensi define_expand and its associated unspec.

Could I suggest that someone tries compiling the following
massive test case:

int
foo (char* s)
{
        return strlen (s);
}

on an i386 box using the options "-O2 -mcpu=pentium" to
confirm it?

You will notice several pages of assembler output rather
than the required four or so lines.

The compiler generates the following RTL:

(insn 10 8 12 (set (reg:SI 23)     // This should be 0; it
        (reg/v:SI 21)) -1 (nil)    // is the end-of-string
    (nil))
(insn 12 10 13 (set (reg:SI 22)    // This is the char*
        (reg/v:SI 21)) -1 (nil)
    (nil))
(insn 13 12 15 (parallel[ 
            (set (reg:SI 22)
                (unspec:SI[ 
                        (mem:BLK (reg:SI 22)) // Pointer
                        (const_int 1) // This should be e-o-s
                        (reg:SI 23)   // Alignment: should be 1
                    ]  0))
            (clobber (reg:SI 23))
        ] ) -1 (nil)
    (nil))

The several pages of guff are due to it thinking it has
some wonderful news about alignment that it can do something
smart with.  The fact that it doesn't go looking for a string
that ends with 1 is because that param isn't ever actually
explicitly refered to or USEd anywhere; the md constrains it
to be in the correct register which is futile as it will be
eliminated as it doesn't appear to the compiler to be needed.

With my previously submitted patch the RTL generated becomes
much more realistic:

(insn 10 8 12 (set (reg:QI 23)	// The end-of-string put
        (const_int 0)) -1 (nil) // in a QI register (%ax)
    (nil))
(insn 12 10 13 (set (reg:SI 24)	// The char *s
        (reg/v:SI 21)) -1 (nil)
    (nil))
(insn 13 12 14 (parallel[ 
            (set (reg:SI 25)
                (unspec:SI[ 
                        (mem:BLK (reg:SI 24))	// Pointer
                        (reg:QI 23)		// The e-o-s
                        (const_int 1)		// Alignment
                    ]  0))
            (use (reg:QI 23))
            (clobber (reg:SI 24))
        ] ) -1 (nil)
    (nil))

The problems alluded to in my previous message are likely
due to the particular circumstances that the crap RTL was
generated within causing subsequent failures in generated
code.


   Alasdair.