Hello Segher, all,
I have the impression there is a small bug in the front-end.
//#define LOAD_EXTEND_OP(MODE) ZERO_EXTEND
#define LOAD_EXTEND_OP(MODE) UNKNOWN // HACK HENRI !!.
(this is in my back-end)
I have to turn the LOAD_EXTEND_OP(MODE) to UNKNOWN.
The issue seems to be following:
- There are operations in the code of the type
R100:SI = zero_extend(R101:HI)
- Now, during reload, R101:HI is moved on the stack.
- Then, internally in the compiler, there is confusion on the
zero_extend operator.
a. If the load-extend-mode is ZERO_EXTEND:
there is confusion as to use the MOVHI instruction or the
ZERO_EXTEND instruction.
(they both do the same.) This seems to lead to the strange bugs.
(It seems to me there are optimizers that recognize the
ZERO_EXTEND as MOVHI, and others
that dont, leading to the crashes.)
b. If I turn it off, all seems to go OK.
- So, I turned it off ... Hope this does not lead to problems.
Best Regards,
Henri.
On 11/3/20 6:23 PM, Segher Boessenkool wrote:
Hi Henri,
On Tue, Nov 03, 2020 at 04:25:32PM +0100, Henri Cloetens wrote:
583: r990:SI=zero_extend(r378:SI#0)
- The statement (r378:SI#0) takes the '0' subreg form reg r378:SI.
(shorthand in the reload dump.)
And it doesn't say what mode subreg it is (QImore or HImode here).
There are multiple cases like this, where the abbreviated RTL is not
conclusive (so cannot be parsed back).
(define_insn "zero_extendhisi2_internal"
[(set (match_operand:SI 0 "gpc_reg_operand" "=r,r,r")
(zero_extend:SI (match_operand:HI 1 "movhi_operand_0"
"Z,C,r")))]
- However, the predicate "r" in the statement above, does not allow a
subreg.
Yes it does. See register_operand in recog.c for example. It is of
course possible your gpc_reg_operand doesn't allow it (bad idea, but I
don't know your code).
You would normally start the gpc_reg_operand code with something like
if (SUBREG_P (op))
op = SUBREG_REG (op);
(as well as pretty much all other register operand predicates).
Segher
