public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "joern dot rennecke at st dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/20396] TRULY_NOOP_TRUNCATION ignored
Date: Mon, 11 Apr 2005 12:36:00 -0000	[thread overview]
Message-ID: <20050411123622.7134.qmail@sourceware.org> (raw)
In-Reply-To: <20050309211545.20396.amylaar@gcc.gnu.org>


------- Additional Comments From joern dot rennecke at st dot com  2005-04-11 12:36 -------
Subject: Re:  TRULY_NOOP_TRUNCATION ignored

echristo at redhat dot com wrote:

>------- Additional Comments From echristo at redhat dot com  2005-04-10 19:02 -------
>I think I'm ok with this, but I'd like a bit more info. What changes to the
>backend do you forsee this needing? The one patch that you applied to the 4.1 sh
>branch was too big to just get that particular set of changes.
>
>  
>
[assuming you are talking about generating TRUNCATE in gen_lowpart_common]

First. some source operands will have a TRUNCATE, and if your expander 
tries to make
all operands fit, or thinks it knows all the codes that can occur in 
some position, it will have
to be updated to cope with the TRUNCATE.
This is unfortunately also true for destination operands.  Also, when 
you use gen_lowpart
for a non-TRULY_NOOP_TRUNCATION mode pair, in a splitter or a peephole, 
for a
destination, or for an operand where due to the nature of the operation 
or the register class
being used a SUBREG is desired, you will still get a TRUNCATE; you have 
to use
simplyfy_gen_subreg to explicitly get a SUBREG.
The splitter with the for_each_rtx application of 
shmedia_cleanup_truncate cleans up such
stuff after reload.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20396


  parent reply	other threads:[~2005-04-11 12:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-09 21:16 [Bug middle-end/20396] New: " amylaar at gcc dot gnu dot org
2005-03-09 21:18 ` [Bug middle-end/20396] " amylaar at gcc dot gnu dot org
2005-04-05 15:36 ` amylaar at gcc dot gnu dot org
2005-04-08 17:04 ` amylaar at gcc dot gnu dot org
2005-04-08 17:45 ` cvs-commit at gcc dot gnu dot org
2005-04-08 18:23 ` amylaar at gcc dot gnu dot org
2005-04-08 18:28 ` cvs-commit at gcc dot gnu dot org
2005-04-10 19:02 ` echristo at redhat dot com
2005-04-11 12:36 ` joern dot rennecke at st dot com [this message]
2005-04-11 19:54 ` echristo at redhat dot com
2005-04-12 17:42 ` pinskia at gcc dot gnu dot org
2005-05-13 18:34 ` amylaar at gcc dot gnu dot org
2005-07-12 13:46 ` cvs-commit at gcc dot gnu dot org
2005-07-31  2:43 ` pinskia at gcc dot gnu dot org
2005-08-16 12:03 ` cvs-commit at gcc dot gnu dot org
2005-08-16 12:12 ` pinskia at gcc dot gnu dot org

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=20050411123622.7134.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).