Question about make_extraction() in combine.c

[Michael Eager]

On 8/28/19 12:33 PM, Segher Boessenkool wrote:
> Hi!
> 
> 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.
> 
> How?

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