From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30414 invoked by alias); 25 Nov 2004 15:33:19 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 30383 invoked from network); 25 Nov 2004 15:33:12 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 25 Nov 2004 15:33:12 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iAPFXCDI022945 for ; Thu, 25 Nov 2004 10:33:12 -0500 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iAPFXCr18300; Thu, 25 Nov 2004 10:33:12 -0500 Received: from vpn83-123.boston.redhat.com (IDENT:U2FsdGVkX19KH8cVbijmoK0XnA9V+PsBrnOhLGvb8WU@vpn83-123.boston.redhat.com [172.16.83.123]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id iAPFXAoS010371; Thu, 25 Nov 2004 10:33:11 -0500 Subject: [RFC] ignoring type alias conflicts between structures and scalars From: Diego Novillo To: "gcc@gcc.gnu.org" Cc: Jeff Law Content-Type: multipart/mixed; boundary="=-zT39cbxauUp82lmM5x6h" Organization: Red Hat Canada Date: Thu, 25 Nov 2004 15:38:00 -0000 Message-Id: <1101396789.31231.84.camel@localhost.localdomain> Mime-Version: 1.0 X-SW-Source: 2004-11/txt/msg00962.txt.bz2 --=-zT39cbxauUp82lmM5x6h Content-Type: text/plain Content-Transfer-Encoding: 7bit Content-length: 1997 Jeff noticed that TBAA was creating some alias relations that don't seem to make much sense. For instance, given ------------------------------------------------------------------------------------struct int_float_s { int i; float f; }; int X; foo() { struct int_float_s *x = bar(); X = 10; x->i = 3; return X; } ------------------------------------------------------------------------------------ After TBAA, we had Variable: x, UID 1, struct int_float_s *, type memory tag: TMT.0 Variable: X, UID 2, int, is addressable, is global, call clobbered, default def: X_1 Variable: TMT.0, UID 5, struct int_float_s, is addressable, is global, call clobbered, may aliases: { X } Jeff's argument is that it's not really possible for a pointer to a structure to point to a scalar variable. If the structure is not type compatible with the scalar, then they can't alias. That makes some sense to me. However, the front end says that those two types are alias compatible, meaning that we could store into X via x. So, I'm confused. I discussed this a bit with Nathan and Joseph on IRC. Nathan pointed me to some section in the C standard that seems to support the fact that indeed TMT.0 should alias X. The attached patch implements the idea of ignoring alias relations between structures and scalars that are not type compatible. It survived bootstrap and testing on x86, ia64, x86-64 and ppc. However, I have zero confidence in it. If the types cannot really conflict, alias_sets_conflict_p() should tell me so. I shouldn't need to short circuit it this way. I'm also attaching a program that breaks this patch. Basically, it causes 'bar()' to return &X. Since we are now considering that X cannot alias with TMT.0, we would optimize the function to 'return 10'. The question is: Is the program well defined? If the program isn't well defined, why is alias_sets_conflict_p() saying that 'struct int_float_s' and 'int' have conflicting alias sets? Thanks. Diego. --=-zT39cbxauUp82lmM5x6h Content-Disposition: attachment; filename=20041125-short-circuit-struct-scalar-alias.diff Content-Type: text/x-patch; name=20041125-short-circuit-struct-scalar-alias.diff; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-length: 1265 Index: tree-ssa-alias.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/tree-ssa-alias.c,v retrieving revision 2.56 diff -d -c -p -u -r2.56 tree-ssa-alias.c --- tree-ssa-alias.c 24 Nov 2004 14:46:23 -0000 2.56 +++ tree-ssa-alias.c 25 Nov 2004 14:26:09 -0000 @@ -928,7 +928,21 @@ compute_flow_insensitive_aliasing (struc || is_call_clobbered (var); if (!tag_stored_p && !var_stored_p) continue; - + + /* A scalar variable cannot be aliased with a structure if + their types are not compatible. ??? But then, why would + alias_sets_conflict_p say that their alias sets are in + conflict? Given a memory tag of type 'struct X { int b; + float a; }' and a variable of type 'int', their alias + sets are considered to conflict, but it doesn't seem + possible that a 'struct X *' may point to the 'int' + variable. */ + if (TREE_CODE (TREE_TYPE (tag)) == RECORD_TYPE + && !AGGREGATE_TYPE_P (TREE_TYPE (var)) + && !lang_hooks.types_compatible_p (TREE_TYPE (tag), + TREE_TYPE (var))) + continue; + if (may_alias_p (p_map->var, p_map->set, var, v_map->set)) { size_t num_tag_refs, num_var_refs; --=-zT39cbxauUp82lmM5x6h Content-Disposition: attachment; filename=b.c Content-Type: text/x-csrc; name=b.c; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-length: 196 struct int_float_s { int i; float f; }; int X; int *ptr_to_X () { return &X; } foo() { struct int_float_s *x = (struct int_float_s *) ptr_to_X (); X = 10; x->i = 3; return X; } --=-zT39cbxauUp82lmM5x6h--