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
next prev parent 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).