On 5/5/2021 7:50 AM, Tobias Burnus wrote:
Hi Eric, hi all,
currently, gcn (amdgcn-amdhsa) bootstrapping fails as Alexandre's
patch to __builtin_memset (applied yesterday) now does more expansions.
The problem is [→ PR100418]
(set(reg:DI)(plus:DI(reg:DI)(const_int))) [= "adddi3"]
This fails with gcn as gcn has two clobbers for "adddi3" - and when
expand_insn
is called, INSN_CODE == -1 via:
icode = recog_memoized (insn);
alias
INSN_CODE (insn) = recog (PATTERN (insn), insn, 0);
As the "int *pnum_clobber" argument is NULL (well, '0'), the
clobbers are not available - which causes the pattern fail.
I think that's a general issue with the RTX code generated by
builtins.c – except that most targets either do not
have clobbers for the used operators — or the code is by
chance fixed:
For instance, I see that several "if" blocks being processed in
recog.c's insn_invalid_p via 'cleanup_cfg (CLEANUP_NO_INSN_DEL)';
the innermost parts of the call chain are:
apply_change_group → verify_changes → insn_invalid_p
* * *
The attached patch seems to solve the GCN issue. Does it look OK?
Or does the insn_invalid_p call come too late?
If so, any suggestion where it would fit best?
Tobias,
who is more a FE and early-ME person.
-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung,
Frank Thürauf
recog.diff
extract_insn: Call insn_invalid_p is insn cannot be found.
gcc/ChangeLog:
* recog.c (extract_insn): Call insn_invalid_p if
recog_memoized did not find the insn.
Was this issue on GCN fixed by Andrew/Jakub's change to use
force_operand rather than emit_move_insn?
Jeff
