qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 05/25] tcg: Allow extra data to be attached t


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH v3 05/25] tcg: Allow extra data to be attached to insn_start
Date: Wed, 23 Sep 2015 09:37:22 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0

On 09/23/2015 07:55 AM, Kevin O'Connor wrote:
> On Tue, Sep 22, 2015 at 01:24:47PM -0700, Richard Henderson wrote:
>> With an eye toward having this data replace the gen_opc_* arrays
>> that each target collects in order to enable restore_state_from_tb.
> 
> Hi Richard,
> 
> Instead of having each architecture front-end determine the constants
> to be restored on an exception, have you considered having the tcg
> liveness pass automatically detect them?
> 
> What I was thinking was if:
> - each front-end stored each constant on every instruction using
>   regular "movi" ops
> - tcg_liveness_analysis() tracked which global memory "sync" writes
>   are purely due to an op that can raise an exception
> - then tcg_liveness_analysis() could remove "movi" instructions with
>   outputs that are needed only during an exception and place the
>   constant directly in the compressed table itself.
> 
> I'm curious if this was considered and if there is a reason it
> wouldn't work well.

We certainly don't have enough information to infer something like that.

The moment we reach a helper that isn't marked as TCG_CALL_NO_WG, all that
inference has to go out the window ans we have to assume that the "movi op" is
both necessary and overwritten.

The knowledge of which helpers modify a field such as cc_op is present into the
translators in code form.  It would require significant effort to change that.


r~



reply via email to

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