From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10275 invoked by alias); 16 Oct 2004 03:10:39 -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 10229 invoked from network); 16 Oct 2004 03:10:38 -0000 Received: from unknown (HELO vlsi1.ultra.nyu.edu) (128.122.140.213) by sourceware.org with SMTP; 16 Oct 2004 03:10:38 -0000 Received: by vlsi1.ultra.nyu.edu (4.1/1.34) id AA24908; Fri, 15 Oct 04 23:14:23 EDT Date: Sat, 16 Oct 2004 12:34:00 -0000 From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner) Message-Id: <10410160314.AA24908@vlsi1.ultra.nyu.edu> To: roger@eyesopen.com Subject: Re: fold_convert question Cc: gcc@gcc.gnu.org X-SW-Source: 2004-10/txt/msg00651.txt.bz2 But "fold" itself calls "fold_convert" to ensure/force a tree to a specified type. i.e. fold_convert is called for both generic, gimple and potentially even by front-ends that don't use tree-ssa. Hmm ... I agree completely that the problem is one of consistency, but I would argue that the bug is in (this use of) STRIP_USELESS_TYPE_CONVERSIONS. It's not that fold_convert is broken, but that the VIEW_CONVERT_EXPR shouldn't have been stripped off in the first place. I probably wouldn't consider the conversion of an ARRAY_TYPE to a scalar to be useless? It's not a conversion between arrays and scalars, but between two ARRAY_TYPEs. Otherwise, they wouldn't have been compartible! (Ada says that two ARRAY_TYPEs are compatible if the component types are compatible and the bounds are the same.) Indeed the fact that VIEW_CONVERT_EXPR is only used by Ada probably helps explain why S_U_T_C is overly aggressive in removing it. For the majority of front-ends (and Ada uses) fold_convert does the right thing. I added the removal of the VIEW_CONVERT_EXPR to S_U_T_C and I still believe it should be there. tree_ssa_useless_type_conversion is an unfortunate hack to work around the fact that tree-ssa doesn't yet have a combiner pass. Without a combiner, the optimization passes can only see one statement and its operands at a time, so the "necessary" type conversions required to keep operands consistent often create a "horizon affect" where optimization opportunities are missed due to the local nature of SSA form. Perhaps, but I don't see it that way. It's always better to keep code at any level of representation as simple as possible. If we have conversions that we know aren't going to generate any code, the earlier we remove them the better. If there's anything I can do to help you investigate/fix c61008a that avoids further degenerating the middle-end's type system, I'd be happy to help. Ultimately, this might be a loosing crusade, but I couldn't forgive myself if I didn't try. Worst case scenario of tweaking useless_type_conversions is that we miss some optimizations (until we get a tree-ssa combiner), but of perverting fold_convert is that we regress many difficult to diagnose code generation bugs. The investigation of that failure is, to a large extent, secondary. We have the larger problem of being careful to define what "type correctness" means at tree level. I previously thought it was uniformly agreed that it means "strictly correct" in GENERIC and "compatible" (as defined by the lang hook) in GIMPLE. So the first question we need to answer is if that's correct or not. If it is, then we need to understand which of the tests fold_convert ought to use based on when it's called. It may well be that the bug here is in the caller, which shouldn't be calling it if the types are already compatible.