Rask Ingemann Lambertsen wrote: > On Tue, Jun 19, 2007 at 11:11:54AM +0200, Uros Bizjak wrote: > >> On 6/19/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> 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