On Mon, Aug 31, 2009 at 4:36 PM, Richard Henderson<[email protected]> wrote:
> On 08/31/2009 01:07 PM, Jean Christophe Beyler wrote:
>>
>> If I replace this :
>> (define_insn "extzv"
>>   [(set (match_operand 0 "register_operand" "")
>>         (zero_extract (match_operand 1 "register_operand" "")
>>                       (match_operand 2 "const_int_operand" "")
>>                       (match_operand 3 "const_int_operand" "")))]
>>  ""
>>  "")
>
> Well, I can tell you that an insn pattern with no modes
> on the non-immediate operands will definitely cause problems.

Yes that was a mistake on my part, I wanted a define_expand instead.

>> (insn 9 8 10 3 struct4.c:24 (set (subreg:DI (reg:QI 76) 0)
>>         (zero_extract:DI (reg:DI 75)
>>             (const_int 1 [0x1])
>>             (const_int 0 [0x0]))) -1 (nil))
>>
>> (insn 10 9 11 3 struct4.c:24 (set (reg:DI 77)
>>         (zero_extend:DI (reg:QI 76))) -1 (nil))
>>
>> Is there anything I can do to remove that zero_extend?
>
> You could try either using a predicate that disallows
> a subreg, or by having your expander rewrite things into
>
>  (set (reg:DI new-scratch))
>       (zero_extract:DI ...))
>  (set (reg:QI 76 (subreg:QI (reg:DI new scratch)))
>
> and relying on subsequent passes to clean that up.

I am going to try this but shouldn't it be :

(set (reg:QI new-scratch))
      (zero_extract:DI ...))
(set (reg:DI 76 (subreg:DI (reg:QI new scratch)))

?


I did this:
    if (GET_CODE (operands[0]) != REG)
    {
        rtx tmp = gen_reg_rtx (DImode);
        emit_insn (gen_extzvdi2 (tmp, operands[1], operands[2], operands[3]));
        emit_move_insn (operands[0], tmp);
        DONE;
    }

Which generates in my case :
(insn 9 8 10 3 struct4.c:33 (set (reg:DI 77)
        (zero_extract (reg:DI 75)
            (const_int 1 [0x1])
            (const_int 0 [0x0]))) -1 (nil))

(insn 10 9 11 3 struct4.c:33 (set (subreg:DI (reg:QI 76) 0)
        (reg:DI 77)) -1 (nil))

(insn 11 10 12 3 struct4.c:33 (set (reg:DI 78)
        (zero_extend:DI (reg:QI 76))) -1 (nil))

As we can see, I still have that zero_extend but maybe it can be
simplified afterwards. I don't know because, now, it fails at the same
place in :

struct4.c:35: internal compiler error: in simplify_subreg, at
simplify-rtx.c:4923
-> This line is the second assert of function simplify_subreg :
gcc_assert (outermode != VOIDmode);

The outermode is VoidMode and the op given to the function is the following :
(ashift:DI (mem/s:DI (reg/v/f:DI 72 [ t ]) [0 S8 A64])
    (const_int -1 [0xffffffff]))

I don't know where this ashift is from since it doesn't appear in any
of the previous passes.

Any ideas?

As always, thanks,
Jc

Reply via email to