This is the mail archive of the
mailing list for the GCC project.
Re: Question about make_extraction() in combine.c
- From: Michael Eager <eager at eagerm dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Jeff Law <law at redhat dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>
- Date: Thu, 29 Aug 2019 08:28:46 -0700
- Subject: Re: Question about make_extraction() in combine.c
- References: <email@example.com> <20181116225022.GM23873@gate.crashing.org> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <20190828193336.GG31406@gate.crashing.org>
On 8/28/19 12:33 PM, Segher Boessenkool wrote:
On Tue, Aug 27, 2019 at 09:37:59AM -0700, Michael Eager wrote:
Combine is complex, but I don't think that target descriptions should
conform to its behaviors;
But they have to, in some ways. If combine writes something that can be
written in multiple ways in some way X, then your machine description has
to recognise X (perhaps in addition to other ways it can be written), or
you will not get as much optimisation as you might like: some combine
attempts will fail.
combine should adapt to the target.
By not making arbitrary restrictions on the instructions which a target
can implement, simply to avoid a bug in a different target.
The target has an instruction which can extract a bit (or bit field)
from a word in memory. The code in combine prevents that instruction
from being used without creating awkward workarounds.
diff --git a/gcc/combine.c b/gcc/combine.c
index 93bd3da26d7..fdc79ab7d3e 100644
@@ -7777,17 +7777,7 @@ make_extraction (machine_mode mode, rtx inner, HOST_WIDE_INT pos,
This patch is against some older version of combine.c? The line number is
off by 70 or so.
The patch was created last November.
&& partial_subreg_p (extraction_mode, mode))
extraction_mode = mode;
And current trunk has here
/* Punt if len is too large for extraction_mode. */
if (maybe_gt (len, GET_MODE_PRECISION (extraction_mode)))
(See r268913, https://gcc.gnu.org/ml/gcc-patches/2019-02/msg01140.html ).
This patch seems unrelated.
Does that fix your problem already? Is more needed? Is your patch
removing some now-dead code?
If you are asking, does my patch remove code that is no longer needed to
fix the decades-old problem which it fixed (or hid)? I suspect it does.
But this cannot be verified. There's no test case for the original
problem, nor is it clear which architecture had the problem.
Michael Eager email@example.com
1960 Park Blvd., Palo Alto, CA 94306