This is the mail archive of the 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]

riscv64 dep. computation


While working on a private port of riscv, I noticed that upstream shows
the same behaviour.

For the code:
#define TYPE unsigned short

struct foo_t
  TYPE a;
  TYPE b;
  TYPE c;

func (struct foo_t *x, struct foo_t *y)
  y->a = x->a;
  y->b = x->b;
  y->c = x->c;

If I compile this with -O2, sched1 groups all loads and all stores
together. That's perfect. However, if I change TYPE to unsigned char and
recompile, the stores and loads are interleaved.

Further investigation shows that for unsigned char there are extra
dependencies that block the scheduler from grouping stores and loads.

For example, there's a dependency between:
(insn 8 3 9 2 (set (mem:QI (reg/v/f:DI 76 [ yD.1533 ]) [0
y_6(D)->aD.1529+0 S1 A8])
        (subreg/s/v:QI (reg:DI 72 [ _1 ]) 0)) "test.c":13:8 142
     (expr_list:REG_DEAD (reg:DI 72 [ _1 ])

(insn 11 10 12 2 (set (reg:DI 74 [ _3 ])
        (zero_extend:DI (mem:QI (plus:DI (reg/v/f:DI 75 [ xD.1532 ])
                    (const_int 2 [0x2])) [0 x_5(D)->cD.1531+0 S1 A8])))
"test.c":15:11 89 {zero_extendqidi2}
     (expr_list:REG_DEAD (reg/v/f:DI 75 [ xD.1532 ])

which didn't exist in the `unsigned short' case.

I can't find where this dependency is coming from but also can't justify
it so it seems like a bug to me. Is there a reason for this to happen
that I might not be aware of?

While I am at it, debugging compute_block_dependencies in sched-rgn.c is
a massive pain. This calls sched_analyze which receives a struct
deps_desc that tracks the dependencies in the insn list. Is there a way
to pretty print this structure in gdb?

Kind regards,

Paulo Matos

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