Re: virtual stack regs.

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

Rask Ingemann Lambertsen wrote:
> On Tue, Jun 19, 2007 at 11:11:54AM +0200, Uros Bizjak wrote:
>   
>> On 6/19/07, Rask Ingemann Lambertsen <rask@sygehus.dk> wrote:
>>     
>>>   It is possible to mess up the substitution that the vregs pass performs.
>>> IIRC, it happened to me once because I accidentally put one of these 
>>> virtual
>>> pseudo inside a (clobber) or (use) or something like that. I don't quite
>>> recall the details, but maybe the substitution fails if they appear outside
>>> an operand?
>>>       
>> There is one annoying case in PR32374, where on-the-stack constructor
>> creates invalid memory clobber that includes virtual-stack-regs. These
>> are simply ignored by vregs pass and this confuses dataflow register
>> initialization.
>>     
>
>    Yes, that sure rings a bell with me. A "bare" (clobber) with a
> virtual-what-have-we reg inside it does the trick nicely. If it hadn't
> been hidden inside a MEM, you would have seen the rnreg pass choke on it,
> IIRC.
>
>    My DKK 0.02 worth: I don't see the point in clobbering a memory location
> just before storing into it. We do so with pseudos wider than BITS_PER_WORD
> just before storing into all BITS_PER_WORD sized subregs of it, but that's
> because life analysis doesn't (didn't?) handle subregs in a useful way. We
> shouldn't do the same for MEMs.
>   
These two mails are the useful information in this whole thread!!

I think that the obvious thing to do is to fix this upstream where the
clobber is being created, especially if the clobber really is invalid as
Rask asserts. 

While I now see enough so that i could easily teach the init-regs pass
to ignore these, I prefer to leave init-regs as is and get rid of the
"invalid" code earlier.  The problem with fixing it in init-regs is that
we have spent a lot of effort and will continue to make the rtl back end
a lot smarter.  It is generally true that if one part finds something
wrong, just fixing that part so that it ignores a problem will
eventually leave it for another part to trip over when it gets smarter.

Since it sounds like you understand this, are either of you willing/able
to attack the problem at it's source?

Kenny