[Bug debug/54693] VTA guality issues with loops

jakub at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Oct 19 12:34:00 GMT 2012


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54693

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-10-19 12:34:14 UTC ---
Thanks, the threadedge patch looks reasonable (I think gimple_location on debug
stmts is ignored, so we don't need to drop it).

As for ivopts, there is no use in these cases.  We'd either need to add debug
uses of IVs as a special set of uses (perhaps in a different vector), that
wouldn't be used for decision of which IVs to keep/use, but just for
computation of the best candidate for it (where for debug info best is
something very different from best for code, for debug info smaller cost is as
small as possible expression, as few address expressions in it as possible, as
few SSA_NAMEs as possible).
Or I guess another alternative for unused IVs used in debug stmts is do what
your loop does (but drop the PHI check and do it for all unused IVs?; in the
particular testcase before your threadedge change the DEBUG stmts use i_10,
which is i_16 + 1 (where i_16 is set in PHI <i_10, 0>), so it wouldn't do
anything).  You can build an artificial temporary use object,
get_computation_at
only uses the iv field of it (so just struct iv_use use; memset (&use, 0,
sizeof (use)); use.iv = info->iv;, for stmt I'd use for PHI setters
gsi_after_labels stmt, for normal assignments next stmt after the setter it if
any.  And for cand perhaps go through all of the (or just a subsect of)
iv_cands that are
iv_use (data, i)->selected for some i.  Perhaps we can first search for a
cand->iv with equal step to the unused iv if any (and prefer integer bases over
more complex ones, on this testcase the removed iv used by some DEBUG stmts is:
ssa name i_10
  type int
  base 1
  step 1
  is a biv
and iv_cands that are selected by any uses are:
  type unsigned long
  base (unsigned long) &arr
  step 1
  base object (void *) &arr
and
  type unsigned int
  base 48
  step 1
where better is to use the second one, both because it has an integer base, and
because TYPE_MODE of its type is identical to TYPE_MODE of the iv (so no
extension/truncation is needed).  get_computation_at returns possibly large
tree, so we need to gimplify it into perhaps series of debug temps, finally
assign to a debug temp after the setter stmt, then rewrite all the debug stmt
uses to use this debug temp.



More information about the Gcc-bugs mailing list