Re: what are the requirements on target/ code for -icount to work correctly?

[Peter Maydell]

On Fri, 19 Jun 2020 at 13:55, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> On 19/06/20 14:39, Peter Maydell wrote:
> > On Fri, 19 Jun 2020 at 13:37, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >>
> >> On 19/06/20 14:18, Peter Maydell wrote:
> >>> On Fri, 19 Jun 2020 at 12:16, Paolo Bonzini <pbonzini@redhat.com> wrote:
> >>>>
> >>>> On 19/06/20 07:46, Pavel Dovgalyuk wrote:
> >>>>> I think, that we need some efforts from target maintainers to remove 
> >>>>> all such calls.
> >>>>
> >>>> I'll take care of target/i386 (which does need one of the three
> >>>> gen_io_end calls that are left).
> >>>
> >>> So why does it need it ? Why can't it just rely on "TB going to
> >>> end anyway which will clear the can_do_io flag" ?
> >>
> >> Because the TB is not always going to end in that case that is left.
> >
> > OK, so when is it valid not to end the TB after an IO instruction ?
> > My initial belief was that the TB should *always* end.
>
> You're right, cpu_io_recompile works only for memory accesses so that
> third one has to be fixed.

Cool. This is starting to sound like the right cleanup is going to be:

 * get rid of all the existing callsites in targets (possibly
   including forcing end-of-TB if the code wasn't doing that before)
 * add an assert that the TB really did end (easy for targets using
   the common-translator-loop, would need to go in per-target code
   for the targets that aren't [cris, lm32, microblaze, moxie, nios2,
   tilegx, unicore32])
 * inline gen_io_end into its one remaining callsite in gen_tb_start()

thanks
-- PMM