This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/20396] TRULY_NOOP_TRUNCATION ignored
- From: "joern dot rennecke at st dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 11 Apr 2005 12:36:22 -0000
- Subject: [Bug middle-end/20396] TRULY_NOOP_TRUNCATION ignored
- References: <20050309211545.20396.amylaar@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot 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