On Fri, 23 Sep 2016, Laurent Desnogues wrote:
> 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.
Does the number of ops depend on the system for which TCG is generating
code? (I'm building QEMU for 32-bit x86.) If 32-bit systems require
twice as many ops as 64-bit systems, maybe the existing value should be
doubled, so using 532 (plus whatever is needed to allow for extra ops from
optimization etc.) - or made conditional on the system for which code is
generated.
> That being said st1 {v0.16b-v3.16b}, [x1], #64 generates even more ops
> with 258.
My empirical observations are only from examining cases where QEMU gives
errors running GCC tests; it's quite possible some instructions aren't
covered, or that the relevant tests got lucky and avoided buffer overruns
despite generating too many ops.
--
Joseph S. Myers
jos...@codesourcery.com
