public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Brooks Moses <brooks.moses@codesourcery.com>
To: gcc-patches@gcc.gnu.org
Cc: fortran@gcc.gnu.org
Subject: Re: RFC: gfc_simplify_transfer implementation.
Date: Tue, 27 Mar 2007 23:39:00 -0000	[thread overview]
Message-ID: <4609A592.9080206@codesourcery.com> (raw)
In-Reply-To: <DB9E8879-3B2A-4F7C-8CFA-66FB35CC8087@lcp.u-psud.fr>

François-Xavier Coudert wrote:
> As soon as I sent the mail, I understood why this sentence is  
> completely wrong. But anyway, is there any reason that the following  
> wouldn't work for taking care of memory representation:
>    - 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
> 
> I guess it's not low overhead, but that way we're relying on the  
> middle-end to get the target memory representation right in all  
> cases :)  And it's probably not so hard to code and test, and then  
> you can refine it if you want to.

Indeed.  That, and your suggestion about using the bit_size fields to 
compute the size, are pretty much the sort of thing I was thinking of 
for how to get the target-memory representation "right" in the 
individual export_expr and import_expr functions, rather than using the 
versions that I've implemented now.  I definitely agree that this sort 
of thing should be pushed off to the middle-end as much as possible.

(Or are you also suggesting that it should be possible to do this for 
the whole expressions, rather than splitting them into components first 
and doing it to the individual components?  That's an interesting 
thought, if true.)

- Brooks

  reply	other threads:[~2007-03-27 23:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-27 21:53 Brooks Moses
2007-03-27 22:05 ` FX Coudert
2007-03-27 22:16   ` François-Xavier Coudert
2007-03-27 23:39     ` Brooks Moses [this message]
2007-03-28  6:16       ` Paolo Bonzini
2007-03-28 17:52 ` Richard Henderson
     [not found] <339c37f20703280927v6fa04329u38088e0d918712e@mail.gmail.com>
     [not found] ` <19c433eb0703280947y10fa6d6bs6b1597bd66af2cc4@mail.gmail.com>
2007-03-28 18:38   ` Brooks Moses

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4609A592.9080206@codesourcery.com \
    --to=brooks.moses@codesourcery.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).