Re: virtual stack regs.
I would like to get some more information about pr32374.
I do not know what virtual_stack_vars are and there is no documentation
in the doc directory.
It is documented:
@findex VIRTUAL_STACK_VARS_REGNUM
@cindex @code{FRAME_GROWS_DOWNWARD} and virtual registers
@item VIRTUAL_STACK_VARS_REGNUM
If @code{FRAME_GROWS_DOWNWARD} is defined to a nonzero value, this
points to immediately above the first variable on the stack. Otherwise,
it points to the first variable on the stack.
1) What are these?
2) Why are they uninitialized?
3) If they really are uninitialized, why is it a problem to assign zero
to them.
Basically like all virtual registers, those are just placeholders used
during expansion for RTL expressions that are fed into the place later.
See instantiate_virtual_regs. As such emitting a store into the
register definitly confuse the logic.
4) If they are not uninitialized, where is the initialization code? Why
does df not see it?
5) How can I tell if a reg is a virtual_stack_reg?
By the regno. If you want to check for all those animals, you need
FIRST_VIRTUAL_REGISTER. Why do you need the dataflow so early?
Honza
Re: virtual stack regs.
On Mon, Jun 18, 2007 at 08:28:25PM -0400, Kenneth Zadeck wrote:
I would like to get some more information about pr32374.
I do not know what virtual_stack_vars are and there is no documentation
in the doc directory.
less -p 'Virtual registers ' gcc/rtl.h
less -p 'enum global_rtl_index' gcc/rtl.h
1) What are these?
They are placeholders. The vregs pass will replace them with
stack_pointer_rtx, (hard_)frame_pointer_rtx and arg_pointer_rtx using
information from STARTING_FRAME_OFFSET, FIRST_PARM_OFFSET and such.
Here are two examples, where arg_pointer_rtx is (reg/f:HI 14 argp) and
(hard_)frame_pointer_rtx is (reg/f:HI 10 bp):
(insn ... (set (reg/v/f:HI 39 [ tmp ])
(mem/f/c/i:HI (plus:HI (reg/f:HI 15 virtual-incoming-args)
(const_int 4 [0x4])) [0 tmp+0 S2 A16])) -1 (nil)
(expr_list ...
(nil)))
becomes
(insn ... (set (reg/v/f:HI 39 [ tmp ])
(mem/f/c/i:HI (plus:HI (reg/f:HI 14 argp)
(const_int 6 [0x6])) [0 tmp+0 S2 A16])) 9 {*movhi} (nil)
(expr_list ...
(nil)))
(where argp is a virtual hard reg later eliminated by reload) because
FIRST_PARM_OFFSET is 2, and
(insn ... (parallel [
(set (reg:HI 62)
(plus:HI (reg/f:HI 16 virtual-stack-vars)
(reg:HI 61)))
(clobber (reg:CC 13 cc))
]) -1 (nil)
(nil))
becomes
(insn ... (parallel [
(set (reg:HI 62)
(plus:HI (reg/f:HI 10 bp)
(reg:HI 61)))
(clobber (reg:CC 13 cc))
]) 44 {*addhi3} (nil)
(nil))
because STARTING_FRAME_OFFSET is 0.
2) Why are they uninitialized?
There is no meaningful value to assign to them.
3) If they really are uninitialized, why is it a problem to assign zero
to them.
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?
4) If they are not uninitialized, where is the initialization code? Why
does df not see it?
Hmm, how do you handle arg_pointer_rtx, frame_pointer_rtx and the like?
The are all uninitialized until the prologue is emitted, which is some time
after reload.
5) How can I tell if a reg is a virtual_stack_reg?
FIRST_VIRTUAL_REGISTER = regno = LAST_VIRTUAL_REGISTER
--
Rask Ingemann Lambertsen
Re: virtual stack regs.
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
Re: virtual stack regs.
On Tue, Jun 19, 2007 at 08:33:52AM -0400, Kenneth Zadeck wrote: Since it sounds like you understand this, are either of you willing/able to attack the problem at it's source? Uros is already at it URL:http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01317.html. -- Rask Ingemann Lambertsen
Re: virtual stack regs.
On 6/19/07, Rask Ingemann Lambertsen [EMAIL PROTECTED] wrote: .. Hmm, how do you handle arg_pointer_rtx, frame_pointer_rtx and the like? The are all uninitialized until the prologue is emitted, which is some time after reload. ARG_POINTER_REGNUM is included in the artificial defs of all blocks (which I think is overly conservative - just having them in the entry block def should be enough). Hence, from dataflow point of view, they are always considered initialized. I think we should probably do something similar for VIRTUAL_STACK_*_REGNUM. 5) How can I tell if a reg is a virtual_stack_reg? FIRST_VIRTUAL_REGISTER = regno = LAST_VIRTUAL_REGISTER -- Rask Ingemann Lambertsen -- #pragma ident Seongbae Park, compiler, http://seongbae.blogspot.com;
Re: virtual stack regs.
ARG_POINTER_REGNUM is included in the artificial defs of all blocks (which I think is overly conservative - just having them in the entry block def should be enough). Hence, from dataflow point of view, they are always considered initialized. I think we should probably do something similar for VIRTUAL_STACK_*_REGNUM. I think we should assert that we don't find virtual regs in dataflow, instead. Paolo
virtual stack regs.
I would like to get some more information about pr32374. I do not know what virtual_stack_vars are and there is no documentation in the doc directory. 1) What are these? 2) Why are they uninitialized? 3) If they really are uninitialized, why is it a problem to assign zero to them. 4) If they are not uninitialized, where is the initialization code? Why does df not see it? 5) How can I tell if a reg is a virtual_stack_reg?
