[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: what are the requirements on target/ code for -icount to work correc
From: |
Peter Maydell |
Subject: |
Re: what are the requirements on target/ code for -icount to work correctly? |
Date: |
Fri, 19 Jun 2020 14:12:03 +0100 |
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