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

question about the ddg construction


Hi, all,
    My current project wants to reuse DDG's infrastructure to get some
loop carried dependency information, I debug these code for a while,
but have some questions, Hope you can
give me some suggestions.

1. my platform is X86,  and gcc version is 4.3.1, when i use -fsms,
and debug the code, found that for the following code, if always
return NULL_RTX:

      /* Make sure this is a doloop.  */
      if ( !(count_reg = doloop_register_get (head, tail)))
      {
        if (dump_file)
          fprintf (dump_file, "SMS doloop_register_get failed\n");
    continue;
      }

when I check the doloop_register_get, and found that it's guarded by a
ifdef "HAVE_doloop_end", even i make clobber the whole compiler,
rebuild the compiler by "CFLAGS='-DHAVE_doloop_end'", it still will
complain error, can't find the gen_doloop_end.

so the first question is:  does SMS is support on X86?

2. because of the problem(1) , i just comment out the above code and
continue to debug the create_ddg code to see how these code work.
but for the following code, i don't know if it does the right thing:

testcase is:
  float dot_product(float *a, float *b)
{
  int i; float c = 0;
  for ( i  = 0; i < 100; i ++)
    c += a[i] + b[i];

  return c;

}


the RTL  for the a[i] + b[i] is:

a:$68 = *($65 + 62)
(insn:HI 14 13 15 3 mod.c:5 (set (reg:SF 68)
        (mem:SF (plus:DI (reg/v/f:DI 65 [ a ])
                (reg:DI 62 [ ivtmp.22 ])) [2 S4 A32])) 97 {*movsf_1} (nil))


b.  $68 = $68 + *( $66 + $62)

(insn:HI 15 14 16 3 mod.c:5 (set (reg:SF 68)
        (plus:SF (reg:SF 68)
            (mem:SF (plus:DI (reg/v/f:DI 66 [ b ])
                    (reg:DI 62 [ ivtmp.22 ])) [2 S4 A32]))) 669
{*fop_sf_comm_sse} (nil))


it should be only  REG_DEP there, no MEM_DEP, but the ddg construction
will assert there are MEM_DEP between these two insn.
the problem is:
2.a
    in ddg construction, it will use   sched_analyze (&tmp_deps, head,
tail)  to compute all intra-loop dependency,  also it  can get right
result for this case
and then it use the following statement to create ddg edge:

 create_ddg_dep_from_intra_loop_link (g, src_node, dest_node, dep)

in this function:(ddg.c)
static void
create_ddg_dep_from_intra_loop_link (ddg_ptr g, ddg_node_ptr src_node,
                                     ddg_node_ptr dest_node, dep_t link)
{
  dep_type t = TRUE_DEP;
  dep_data_type dt = (mem_access_insn_p (src_node->insn)
              && mem_access_insn_p (dest_node->insn) ? MEM_DEP
                                 : REG_DEP);
}

here the source is instruction 15, and dest is instruction 14, link is
compute from sched_analyze,
(gdb) p DEP_TYPE(link)
$73 = REG_DEP_TRUE

but dt will be set as MEM_DEP because both these two instruction is
mem_access_insn, but they are both read, and no mem dependency,
however  there're really REG dependency between these instruction for
pseduo register $68

is that by designed or i missed something?



3. the final question is there any existed optimization phase which
use ddg's code beside sms?



thanks very much.

Tianwei


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