[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