Hello,

On Fri, Sep 23, 2016 at 1:53 AM, Joseph Myers <jos...@codesourcery.com> wrote:
> 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,

Something's odd, I get exactly half of that with 193.

That being said st1 {v0.16b-v3.16b}, [x1], #64 generates even more ops with 258.

Thanks,

Laurent

> 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
>

Reply via email to