Re: [tree-ssa] VLA fixes

[law at redhat dot com]

In message <3E57BCAA dot 5040000 at btinternet dot com>, Graham Stott writes:
 >law at redhat dot com wrote:
 >> In message <1045868446 dot 12027 dot 5 dot camel at frodo>, Diego Novillo writes:
 >>  >On Fri, 2003-02-21 at 17:54, law at redhat dot com wrote:
 >>  >
 >>  >> It doesn't look awful.  In fact, the RTL generated after tree optimizat
 >ions
 >>  >> is actually better than what would be generated without the tree optimi
 >zers
 >>  >.
 >>  >> 
 >>  >Not that :)  What I meant is that we then go on to get an ICE in reload:
 >>  >
 >>  >-------------------------------------------------------------------------
 >----
 >>  >20020412-1.c: In function `main':
 >>  >20020412-1.c:55: error: unable to find a register to spill in class `AREG
 >'
 >>  >20020412-1.c:55: error: this is the insn:
 >>  >(insn 129 128 130 2 0x40220dc0 (set (reg:CCNO 17 flags)
 >>  >        (compare:CCNO (and:SI (reg/v:SI 71 [ T.29 ])
 >>  >                (const_int 3 [0x3]))
 >>  >            (const_int 0 [0x0]))) 205 {testsi_1} (nil)
 >>  >    (expr_list:REG_DEAD (reg/v:SI 71 [ T.29 ])
 >>  >        (nil)))
 >>  >20020412-1.c:55: internal compiler error: in spill_failure, at reload1.c:
 >1924
 >>  >-------------------------------------------------------------------------
 >----
 >>  >
 >>  >Yes, in general RTL that comes out of the tree optimizers looks simpler.
 >> In fact, the failure is directly related to the simpler RTL we generate
 >> for VLAs.
 >> 
 >> The non-gimplified code looks something like this:
 >> 
 >>   x = 4;
 >>   [ ... arbitrary code ... ]
 >>   y = x + 1;
 >>   if ((y & 0x3) != 0)
 >>     whatever
 >> 
 >> 
 >> 
 >> The gimplified code looks like
 >> 
 >>   x = 4;
 >>   [ ... arbitrary code ... ]
 >>   y = 5;
 >>   if ((y & 0x3) != 0)
 >>     whatever
 >> 
 >>   Note the IF statement doesn't appear in GIMPLE -- it's created during
 >>   the tree->rtl conversion process.
 >> 
 >>   Anyway, the particular insn which implements the IF conditional looks lik
 >e
 >>   this:
 >> 
 >> (define_insn "testsi_1"
 >>   [(set (reg 17)
 >>         (compare
 >>           (and:SI (match_operand:SI 0 "nonimmediate_operand" "%*a,r,rm")
 >>                   (match_operand:SI 1 "nonmemory_operand" "in,in,rin"))
 >>           (const_int 0)))]
 >>   "ix86_match_ccmode (insn, CCNOmode)"
 >>   "test{l}\t{%1, %0|%0, %1}"
 >>   [(set_attr "type" "test")
 >>    (set_attr "modrm" "0,1,1")
 >>    (set_attr "mode" "SI")
 >>    (set_attr "pent_pair" "uv,np,uv")])
 >> 
 >> 
 >> Y in the gimplified case doesn't get a register during register allocation,
 >> so we're going to have to reload the SOB.
 >> 
 >> 
 >> The reloading code knows that Y is equivalent to the constant 5.  So it
 >> uses the constant 5 instead of the pseudo holding Y when creating
 >> reloads.
 >> 
 >> Reload selects alternative #1, but for some reason it decides it can't
 >> get AREG (the only register in class #1) and blows up.
 >> 
 >> I'm still investigating.  Ahh, it's nice to look at RTL again :-)
 >> 
 >> [ In the non-gimplified code we don't realize that Y is equivalent to
 >>   (const_int 5) and everything "just works". ]
 >> 
 >> jeff
 >> 
 >> 
 >
 >Silly Q
 >
 >Why doesn't the if get const folded before reload even gets a look in
 >surely we have enough info at RTL level to work out that the if always evalua
 >tes to true?
 > 
 >
 >I must be missing something.
combine misses it, I haven't investigated why yet.  That's on my list
after dealing with the reload/backend issue.  The RTL is valid, just
sub-optimal and it's simply incorrect for reload to choke on valid, but
sub-optimal RTL like that :-)

jeff