This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFA: PR 34415: dbr_schedule vs. uninitialised registers


> Indeed, using LR would fix it.  The code was assuming that LIVE OUT is
> the union of the LIVE IN sets (so no register can become live just be
> crossing a BB), but this is true only of LR.

OK, that's my understanding too.

> ... you aren't looking at the whole story.  resource.c looks at IN sets,
> not OUT sets, so you should compare LIVE and LR IN for basic block 3.

Basic block 2 if I'm not mistaken:

;; Start of basic block ( 0) -> 2
;; bb 2 artificial_defs: { }
;; bb 2 artificial_uses: { u-1(29){ }}
;; lr  in  	 4 [$4] 8 [$8] 28 [$28] 29 [$sp] 31 [$31]
;; lr  use 	 29 [$sp]
;; lr  def 	 6 [$6] 7 [$7] 9 [$9] 10 [$10]
;; live  in  	 4 [$4] 31 [$31]
;; live  gen 	 6 [$6] 7 [$7] 9 [$9] 10 [$10]
;; live  kill	

> LIVE is the logical AND of two problems (LR =
> live-or-must-uninitialized, and UR = maybe-initialized).  The keyword is
> "maybe": r28 is initialized in the loop, so it *is* maybe-initialized in
> the loop body.

Would you mind enhancing/fixing the documentation of DF?  Currently we have

/*----------------------------------------------------------------------------
   COMBINED LIVE REGISTERS AND UNINITIALIZED REGISTERS.

   First find the set of uses for registers that are reachable from
   the entry block without passing thru a definition.  In and out
   bitvectors are built for each basic block.  The regnum is used to
   index into these sets.  See df.h for details.

   Then the in and out sets here are the anded results of the in and
   out sets from the lr and ur
   problems. 
----------------------------------------------------------------------------*/

But there is no UR problem:

/* Scanning is not really a dataflow problem, but it is useful to have
   the basic block functions in the vector so that things get done in
   a uniform manner.  The first four problems are always defined.  The
   last 5 are optional and can be added or deleted at any time.  */
#define DF_SCAN  0 
#define DF_LR    1      /* Live Registers backward. */
#define DF_LIVE  2      /* Live Registers & Uninitialized Registers */
#define DF_RD    3      /* Reaching Defs. */
#define DF_CHAIN 4      /* Def-Use and/or Use-Def Chains. */
#define DF_NOTE  5      /* REG_DEF and REG_UNUSED notes. */

And, according to the comment, it seems that there are 9 problems.

-- 
Eric Botcazou


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]