On Wed, Nov 23, 2016 at 05:53:43PM +0100, Georg-Johann Lay wrote:
> >So why does the define_insn allow it?
>
> Because the insn predicate is register_operand:HI which should be fine
> as it is non-strict RTL. Or are predicates supposed to reject such odd
> operands the backend would never gener
On 11/23/2016 09:53 AM, Georg-Johann Lay wrote:
Segher Boessenkool schrieb:
On Wed, Nov 23, 2016 at 04:58:22PM +0100, Georg-Johann Lay wrote:
Hi, this causes an illegal code issue on avr.
Sorry about that.
[ snip ]
Trying 19 -> 7:
Failed to match this instruction:
(set (reg:HI 45 [ x+3 ])
Segher Boessenkool schrieb:
On Wed, Nov 23, 2016 at 04:58:22PM +0100, Georg-Johann Lay wrote:
Hi, this causes an illegal code issue on avr.
Sorry about that.
[ snip ]
Trying 19 -> 7:
Failed to match this instruction:
(set (reg:HI 45 [ x+3 ])
(zero_extend:HI (reg:QI 25 r25 [ x+3 ])))
Suc
On Wed, Nov 23, 2016 at 04:58:22PM +0100, Georg-Johann Lay wrote:
> Hi, this causes an illegal code issue on avr.
Sorry about that.
[ snip ]
> Trying 19 -> 7:
> Failed to match this instruction:
> (set (reg:HI 45 [ x+3 ])
> (zero_extend:HI (reg:QI 25 r25 [ x+3 ])))
> Successfully matched thi
Hi, this causes an illegal code issue on avr.
Test case (reduced from gcc.dg/builtins-32.c):
extern int signbitf (float);
int test (float x)
{
return signbitf (x);
}
Before combine, the dump reads
(note 4 0 19 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 19 4 3 2 (set (reg:QI 51 [ x+3 ])
(
On Tue, Oct 25, 2016 at 11:40 AM, Segher Boessenkool
wrote:
> This improves a few things in change_zero_ext. Firstly, it should use
> the passed in pattern in recog_for_combine, not the pattern of the insn
> (they are not the same if the whole pattern was replaced). Secondly,
> it handled zero_e
This improves a few things in change_zero_ext. Firstly, it should use
the passed in pattern in recog_for_combine, not the pattern of the insn
(they are not the same if the whole pattern was replaced). Secondly,
it handled zero_ext of a subreg, but with hard registers we do not get
a subreg, inste
