qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH] Add support for a helper with 7 arguments


From: Taylor Simpson
Subject: RE: [PATCH] Add support for a helper with 7 arguments
Date: Sun, 9 Feb 2020 05:08:46 +0000


> On 2/7/20 12:43 PM, Taylor Simpson wrote:
> >
> >> -----Original Message-----
> >> From: Richard Henderson <address@hidden>
> >>
> >> But I encourage you to re-think your purely mechanical approach to the
> >> hexagon port.  It seems to me that you should be doing much more
> during
> >> the translation phase so that you can minimize the number of helpers that
> >> you require.
> >
> > There are a couple of things we could do
> > - Short term: Add #ifdef's to the generated code so that the helper isn't
> >   compiled when there is a fWRAP_<tag> defined.  There are currently ~500
> >   instructions where this is the case.
>
> Definitely.

OK, done.

>
> > - Long term: Integrate rev.ng's approach that uses flex/bison to parse the
> > semantics and generate TCG code.
> There is perhaps an intermediate step that merely special-cases the
> load/store
> insns.  With rare exceptions (hah!) these are the cases that will most often
> raise an exception.  Moreover, they are the *only* cases that can raise an
> exception without requiring a helper call anyway.
>
> There are a number of cases that I can think of:
>
> {
>   r6 = memb(r1)
>   r7 = memb(r2)
> }
>
> qemu_ld   t0, r1, MO_UB, mmu_idx
> qemu_ld   t1, r2, MO_UB, mmu_idx
> mov       r6, t0
> mov       r7, t1
>

Here is the TCG we generate currently.
 movi_i32 tmp0,$0x0
 add_i32 loc2,r1,tmp0
 qemu_ld_i32 loc3,loc2,sb,0
 mov_i32 new_value,loc3
 movi_i32 tmp0,$0x0
 add_i32 loc2,r2,tmp0
 qemu_ld_i32 loc3,loc2,sb,0
 mov_i32 new_value,loc3
 mov_i32 r6,new_value
 mov_i32 r7,new_value
I could work on eliminating the add of zero and the extra copies.  Is TCG able 
to optimize these before emitting the host code?


> {
>   r6 = memb(r1)
>   memb(r2) = r7
> }
>
> qemu_ld   t0, r1, MO_UB, mmu_idx
> qemu_st   r7, r2, MO_UB, mmu_idx
> mov       r6, t0
>
> These being the "normal" case wherein the memops are unconditional, and
> can
> simply use a temp for semantics.  Similarly for MEMOP, NV, or SYSTEM insns
> in
> slot0.
>
> {
>   r6 = memb(r1)
>   if (p0) r7 = memb(r7)
> }
>
> qemu_ld   l0, r1, MO_UB, mmu_idx
> andi      t1, p0, 1
>         brcondi   t1, 0, L1
>         qemu_ld   r7, r2, MO_UB, mmu_idx
>  L1:
> mov       r6, l0
>
> For a conditional load in slot 0, we can load directly into the final
> destination register and skip the temporary.

In general, there will be lots of checks we would need to perform before 
concluding that an instruction can write directly into the destination.  For 
example, we have to make sure no other instruction later in the packet reads 
r7.  Also, we have to check if there are any .new references to r7 - these will 
read from new_value[7].


reply via email to

[Prev in Thread] Current Thread [Next in Thread]