| Summary: | Testcase gcc.dg/tree-ssa/20070302-1.c is broken (unneeded call clobbering) | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Diego Novillo <dnovillo> |
| Component: | middle-end | Assignee: | Diego Novillo <dnovillo> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | gcc-bugs, rguenth |
| Priority: | P3 | Keywords: | alias, missed-optimization |
| Version: | 4.3.0 | ||
| Target Milestone: | 4.5.0 | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2008-01-11 15:57:57 | |
| Attachments: | patch I was toying with | ||
|
Description
Diego Novillo
2008-01-11 14:51:01 UTC
It's doing the correct thing. We have
p_1, name memory tag: NMT.14, is dereferenced, points-to vars: { SFT.3 SFT.7 }
(SFT.3 is x.x, SFT.7 is z.x)
Now, NMT.14 is marked call clobbered:
NMT.14, UID D.1582, struct A, is addressable, score: 40, direct reads: 2, direct writes: 1, indirect reads: 0, indirect writes: 2, call clobbered (passed to call), may aliases: { SFT.3 SFT.7 }
because one of its pointed-to vars is call clobbered (SFT.7, aka z, which is
passed to the call). Here:
static void
compute_tag_properties (void)
{
...
EXECUTE_IF_SET_IN_BITMAP (ma, 0, i, bi)
{
entry = referenced_var (i);
/* Call clobbered entries cause the tag to be marked
call clobbered. */
if (!tagcc && is_call_clobbered (entry))
{
mark_call_clobbered (tag, var_ann (entry)->escape_mask);
tagcc = true;
changed = true;
}
I don't know if we can disable this if var_ann (entry)->escape_mask == ESCAPE_TO_CALL.
I don't know if we need to propagate tags from NMT aliases to the NMT
this way at all - after all we add all subvars of an escaped var to
call clobbered vars already.
So, confirmed - there's a missing optimization.
We even mark all pointed-to vars of value-escaping pointers as call-clobbered.
So I believe NMTs itself need never be call-clobbered. But there's also
hints that we cover bugs somewhere:
FIXME: This is not quite right. They should only be
clobbered if value_escapes_p is true, regardless of whether
they point to global memory or not.
So removing this code and fixing all the bugs would be nice.
It is the cause of a bunch of clobbering. */
Also it is not at all clear to me what MTAG_GLOBAL is all about (and its
appearant relation to call clobbered state).
Let's defer this to stage1. Created attachment 14940 [details]
patch I was toying with
Subject: Bug 34743 Author: rguenth Date: Fri Apr 3 11:16:29 2009 New Revision: 145497 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=145497 Log: 2009-04-03 Richard Guenther <rguenther@suse.de> PR tree-optimization/34743 * gcc.dg/pr38984.c: Remove XFAIL, adjust. * gcc.dg/tree-ssa/20070302-1.c: Remove XFAIL. * gcc.dg/tree-ssa/alias-18.c: Likewise. * gcc.dg/tree-ssa/sra-3.c: Likewise. * gcc.dg/vect/no-vfa-vect-49.c: Likewise. * gcc.dg/vect/no-vfa-vect-53.c: Likewise. * gcc.dg/vect/no-vfa-vect-57.c: Likewise. * gcc.dg/vect/no-vfa-vect-61.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr38984.c trunk/gcc/testsuite/gcc.dg/tree-ssa/20070302-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-18.c trunk/gcc/testsuite/gcc.dg/tree-ssa/sra-3.c trunk/gcc/testsuite/gcc.dg/vect/no-vfa-vect-49.c trunk/gcc/testsuite/gcc.dg/vect/no-vfa-vect-53.c trunk/gcc/testsuite/gcc.dg/vect/no-vfa-vect-57.c trunk/gcc/testsuite/gcc.dg/vect/no-vfa-vect-61.c Fixed for 4.5. |