From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17025 invoked by alias); 28 Mar 2007 18:30:21 -0000 Received: (qmail 17002 invoked by uid 22791); 28 Mar 2007 18:30:20 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 28 Mar 2007 19:30:16 +0100 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HWcuJ-00054b-3C for gcc-patches@gcc.gnu.org; Wed, 28 Mar 2007 20:30:03 +0200 Received: from dnab42a491.stanford.edu ([171.66.164.145]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Mar 2007 20:30:03 +0200 Received: from brooks.moses by dnab42a491.stanford.edu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 28 Mar 2007 20:30:03 +0200 To: gcc-patches@gcc.gnu.org From: Brooks Moses Subject: Re: RFC: gfc_simplify_transfer implementation. Date: Wed, 28 Mar 2007 18:38:00 -0000 Message-ID: <460AB3A3.8060508@codesourcery.com> References: <339c37f20703280927v6fa04329u38088e0d918712e@mail.gmail.com> <19c433eb0703280947y10fa6d6bs6b1597bd66af2cc4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) In-Reply-To: <19c433eb0703280947y10fa6d6bs6b1597bd66af2cc4@mail.gmail.com> Cc: fortran@gcc.gnu.org X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-03/txt/msg01900.txt.bz2 François-Xavier Coudert wrote: >>> - create a constant tree from the constant value >>> - fold_convert the value into the other type of similar length >>> - read back the value from the constant tree >> This is how I thought to do this in the first place. However, you >> right away run into problems with arrays. > > Arrays will be transferred element after element, no? I must be > missing something very basic, because I don't understand what can be a > problem with arrays. Indeed, that would be how I would be expecting it to work, and it works well enough in the host-memory implementation. The slight complication is that we need to convert to a memory buffer and back (requiring fold_convert-ish things twice) to handle partly-overlapping elements, but that's not a big deal and I know how to handle it. As Paola Bonzini (and now Richard Henderson) have pointed out, there's an implementation of something much like this in fold-const.c's native_encode_expr and native_interpret_expr which does a lot of this. At present, my implementation plans are to hack fold-const.c slightly to make those two functions non-static, and then call them from the new export_integer/real and import_integer/real functions. Paul, if you have a look at fold-const.c, you'll see that it _is_ reasonably beyond our wit to get the numerics right -- just for integer and floats, it's about 100 lines of code, and in the floating-point cases that's just setting up a byte array to pass to a back-end hook for interpretation. We could copy all of it, but I don't want to be maintaining it! :) I'm not going to have a chance to work on this before the middle of next week, but I'll get to it as soon as I can. Thanks to everyone for the comments and suggestions! - Brooks