MAX_OP_PER_INSTR is currently 266, reported in commit
14dcdac82f398cbac874c8579b9583fab31c67bf to be the worst case for the
ARM A64 decoder.
Whether or not it was in fact the worst case at that time in 2014, I'm
observing the instruction 0x4c006020 (st1 {v0.16b-v2.16b}, [x1])
generate 386 ops from disas_ldst_multiple_struct with current sources,
plus one op from the call to tcg_gen_insn_start in the loop in
gen_intermediate_code_a64. Furthermore, I see six ops generated after
the loop in gen_intermediate_code_a64, and at least two added
subsequently in optimization, so MAX_OP_PER_INSTR needs to be at least
395. I do not know whether other instructions, or code during or
after the loop in gen_intermediate_code_a64, might actually require
the value to be bigger than 395 (possibly depending on the
instructions translated before the one generating 386 ops), just that
395 is definitely needed for a GCC testcase that generates that
particular instruction. So if there is a reliable methodology to
determine the maximum number of ops that might be generated in (one
pass through that loop, plus the code after that loop, plus
optimization), it should be used instead, and might result in a higher
figure (or maybe a higher figure would be safer anyway).
Signed-off-by: Joseph Myers <jos...@codesourcery.com>
---
diff --git a/tcg/tcg.h b/tcg/tcg.h
index c9949aa..a7fa452 100644
--- a/tcg/tcg.h
+++ b/tcg/tcg.h
@@ -32,7 +32,7 @@
#include "tcg-target.h"
/* XXX: make safe guess about sizes */
-#define MAX_OP_PER_INSTR 266
+#define MAX_OP_PER_INSTR 395
#if HOST_LONG_BITS == 32
#define MAX_OPC_PARAM_PER_ARG 2
--
Joseph S. Myers
jos...@codesourcery.com
