This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about make_extraction() in combine.c

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
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -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)))
     return NULL_RTX;

(See r268913, ).

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
1960 Park Blvd., Palo Alto, CA 94306

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]