On 07/06/16 00:00, Peter Maydell wrote:
> On 6 June 2016 at 21:30, Sergey Fedorov wrote:
>> On 06/06/16 22:28, Pranith Kumar wrote:
>>> On Mon, Jun 6, 2016 at 3:23 PM, Richard Henderson wrote:
On 06/06/2016 10:11 AM, Pranith Kumar wrote:
> If I read it correctly TCG_BAR_SYNC is equivalen
On 6 June 2016 at 21:30, Sergey Fedorov wrote:
> On 06/06/16 22:28, Pranith Kumar wrote:
>> On Mon, Jun 6, 2016 at 3:23 PM, Richard Henderson wrote:
>>> On 06/06/2016 10:11 AM, Pranith Kumar wrote:
If I read it correctly TCG_BAR_SYNC is equivalent to OR of all the
other four barriers. I
On 06/06/16 22:28, Pranith Kumar wrote:
> On Mon, Jun 6, 2016 at 3:23 PM, Richard Henderson wrote:
>> On 06/06/2016 10:11 AM, Pranith Kumar wrote:
>>> If I read it correctly TCG_BAR_SYNC is equivalent to OR of all the
>>> other four barriers. I am not sure if we can just construct SYNC like
>>> th
On Mon, Jun 6, 2016 at 3:23 PM, Richard Henderson wrote:
> On 06/06/2016 10:11 AM, Pranith Kumar wrote:
>>
>> If I read it correctly TCG_BAR_SYNC is equivalent to OR of all the
>> other four barriers. I am not sure if we can just construct SYNC like
>> this or if we need to define it explicitly th
On 06/06/2016 10:11 AM, Pranith Kumar wrote:
If I read it correctly TCG_BAR_SYNC is equivalent to OR of all the
other four barriers. I am not sure if we can just construct SYNC like
this or if we need to define it explicitly though.
AFAICS, sparc membar #sync is stronger.
Compare PowerPC hwsyn
On Mon, Jun 6, 2016 at 12:14 PM, Sergey Fedorov wrote:
> On 06/06/16 18:58, Pranith Kumar wrote:
>> On Mon, Jun 6, 2016 at 11:49 AM, Sergey Fedorov wrote:
>>> On 06/06/16 18:47, Pranith Kumar wrote:
On Mon, Jun 6, 2016 at 11:44 AM, Sergey Fedorov
wrote:
> On 03/06/16 21:27, Pranit
On Mon, Jun 6, 2016 at 11:44 AM, Sergey Fedorov wrote:
> On 03/06/16 21:27, Pranith Kumar wrote:
>> On Thu, Jun 2, 2016 at 5:18 PM, Richard Henderson wrote:
>>>
>>> What if we have tcg_canonicalize_memop (or some such) split off the barriers
>>> into separate opcodes. E.g.
>>>
>>> MO_BAR_LD_B =
On 06/06/16 18:58, Pranith Kumar wrote:
> On Mon, Jun 6, 2016 at 11:49 AM, Sergey Fedorov wrote:
>> On 06/06/16 18:47, Pranith Kumar wrote:
>>> On Mon, Jun 6, 2016 at 11:44 AM, Sergey Fedorov
>>> wrote:
On 03/06/16 21:27, Pranith Kumar wrote:
> On Thu, Jun 2, 2016 at 5:18 PM, Richard He
Sergey Fedorov writes:
> On 03/06/16 21:30, Pranith Kumar wrote:
>> On Thu, Jun 2, 2016 at 9:08 PM, Richard Henderson wrote:
>>> On 06/02/2016 02:37 PM, Sergey Fedorov wrote:
It would give us three TCG operations for each memory operation instead
of one. But then we might like to
On 06/06/16 18:47, Pranith Kumar wrote:
> On Mon, Jun 6, 2016 at 11:44 AM, Sergey Fedorov wrote:
>> On 03/06/16 21:27, Pranith Kumar wrote:
>>> On Thu, Jun 2, 2016 at 5:18 PM, Richard Henderson wrote:
What if we have tcg_canonicalize_memop (or some such) split off the
barriers
int
On 03/06/16 21:27, Pranith Kumar wrote:
> On Thu, Jun 2, 2016 at 5:18 PM, Richard Henderson wrote:
>> Hum. That does seem helpful-ish. But I'm not certain how helpful it is to
>> complicate the helper functions even further.
>>
>> What if we have tcg_canonicalize_memop (or some such) split off t
On Mon, Jun 6, 2016 at 11:49 AM, Sergey Fedorov wrote:
> On 06/06/16 18:47, Pranith Kumar wrote:
>> On Mon, Jun 6, 2016 at 11:44 AM, Sergey Fedorov wrote:
>>> On 03/06/16 21:27, Pranith Kumar wrote:
On Thu, Jun 2, 2016 at 5:18 PM, Richard Henderson wrote:
> What if we have tcg_canonical
On 03/06/16 23:43, Peter Maydell wrote:
> On 3 June 2016 at 20:49, Sergey Fedorov wrote:
>> I'm not so sure about acq/rel flags. Is there any architecture which has
>> explicit acq/rel barriers? I suppose acq/rel memory access instructions
>> are always load-link and store-conditional and thus rel
On 3 June 2016 at 20:49, Sergey Fedorov wrote:
> I'm not so sure about acq/rel flags. Is there any architecture which has
> explicit acq/rel barriers? I suppose acq/rel memory access instructions
> are always load-link and store-conditional and thus rely on exclusive
> memory monitor to support th
On 03/06/16 21:27, Pranith Kumar wrote:
> On Thu, Jun 2, 2016 at 5:18 PM, Richard Henderson wrote:
>> >
>> > Hum. That does seem helpful-ish. But I'm not certain how helpful it is to
>> > complicate the helper functions even further.
>> >
>> > What if we have tcg_canonicalize_memop (or some such
On 03/06/16 21:30, Pranith Kumar wrote:
> On Thu, Jun 2, 2016 at 9:08 PM, Richard Henderson wrote:
>> On 06/02/2016 02:37 PM, Sergey Fedorov wrote:
>>>
>>> It would give us three TCG operations for each memory operation instead
>>> of one. But then we might like to combine these barrier operations
On Thu, Jun 2, 2016 at 5:18 PM, Richard Henderson wrote:
>
> Hum. That does seem helpful-ish. But I'm not certain how helpful it is to
> complicate the helper functions even further.
>
> What if we have tcg_canonicalize_memop (or some such) split off the barriers
> into separate opcodes. E.g.
>
On Thu, Jun 2, 2016 at 9:08 PM, Richard Henderson wrote:
> On 06/02/2016 02:37 PM, Sergey Fedorov wrote:
>>
>>
>> It would give us three TCG operations for each memory operation instead
>> of one. But then we might like to combine these barrier operations back
>> with memory operations in each bac
On 03/06/16 18:45, Richard Henderson wrote:
> On 06/03/2016 08:16 AM, Sergey Fedorov wrote:
>> On 03/06/16 04:08, Richard Henderson wrote:
>> So your suggestion is to generate different TCG opcode sequences
>> depending on the underlying target architecture? And you are against
>> forwarding this t
On 06/03/2016 08:16 AM, Sergey Fedorov wrote:
On 03/06/16 04:08, Richard Henderson wrote:
So your suggestion is to generate different TCG opcode sequences
depending on the underlying target architecture? And you are against
forwarding this task further, to the backend code?
Yes, I would prefer
On 03/06/16 04:08, Richard Henderson wrote:
> On 06/02/2016 02:37 PM, Sergey Fedorov wrote:
>> On 03/06/16 00:18, Richard Henderson wrote:
>>> On 06/02/2016 01:38 PM, Sergey Fedorov wrote:
On 02/06/16 23:36, Richard Henderson wrote:
> On 06/02/2016 09:30 AM, Sergey Fedorov wrote:
>> I
On 06/02/2016 02:37 PM, Sergey Fedorov wrote:
On 03/06/16 00:18, Richard Henderson wrote:
On 06/02/2016 01:38 PM, Sergey Fedorov wrote:
On 02/06/16 23:36, Richard Henderson wrote:
On 06/02/2016 09:30 AM, Sergey Fedorov wrote:
I think we need to extend TCG load/store instruction attributes to
On 03/06/16 00:18, Richard Henderson wrote:
> On 06/02/2016 01:38 PM, Sergey Fedorov wrote:
>> On 02/06/16 23:36, Richard Henderson wrote:
>>> On 06/02/2016 09:30 AM, Sergey Fedorov wrote:
I think we need to extend TCG load/store instruction attributes to
provide information about guest o
On 06/02/2016 01:38 PM, Sergey Fedorov wrote:
On 02/06/16 23:36, Richard Henderson wrote:
On 06/02/2016 09:30 AM, Sergey Fedorov wrote:
I think we need to extend TCG load/store instruction attributes to
provide information about guest ordering requirements and leave this TCG
operation only for
On 02/06/16 23:36, Richard Henderson wrote:
> On 06/02/2016 09:30 AM, Sergey Fedorov wrote:
>> I think we need to extend TCG load/store instruction attributes to
>> provide information about guest ordering requirements and leave this TCG
>> operation only for explicit barrier instruction translatio
On 06/02/2016 09:30 AM, Sergey Fedorov wrote:
I think we need to extend TCG load/store instruction attributes to
provide information about guest ordering requirements and leave this TCG
operation only for explicit barrier instruction translation.
I do not agree. I think separate barriers are m
On 06/02/2016 11:42 AM, Pranith Kumar wrote:
Yes, I am working on adding flag argument to the TCG MemOp which indicates
this.
Please don't. I don't think this is the right way to go.
r~
Sergey Fedorov writes:
> On 31/05/16 21:39, Pranith Kumar wrote:
>> diff --git a/tcg/README b/tcg/README
>> index f4a8ac1..cfe79d7 100644
>> --- a/tcg/README
>> +++ b/tcg/README
>> @@ -402,6 +402,23 @@ double-word product T0. The later is returned in two
>> single-word outputs.
>>
>> Similar
On 02/06/16 00:35, Richard Henderson wrote:
> On 06/01/2016 11:43 AM, Pranith Kumar wrote:
>> All we want to do here is map a barrier instruction from guest to a
>> barrier instruction on hist. This mapping is 1:1 if the host has
>> barrier instructions with matching semantics. Otherwise we generat
On 31/05/16 21:39, Pranith Kumar wrote:
> diff --git a/tcg/README b/tcg/README
> index f4a8ac1..cfe79d7 100644
> --- a/tcg/README
> +++ b/tcg/README
> @@ -402,6 +402,23 @@ double-word product T0. The later is returned in two
> single-word outputs.
>
> Similar to mulu2, except the two inputs T1
On 06/01/2016 11:43 AM, Pranith Kumar wrote:
This is, IMO, confused. Either we should use the C++11 barrier types, or
the Linux barrier types, but not both.
This part of the design is still being fleshed out. The above listing
is all the kinds of barriers we can encounter during translation. M
Hi Richard,
Thanks for the review. I will make the changes you pointed out. One point below:
On Tue, May 31, 2016 at 4:24 PM, Richard Henderson wrote:
> On 05/31/2016 11:39 AM, Pranith Kumar wrote:
>> +/* TCGOpmb args */
>> +#define TCG_MB_FULL ((TCGArg)(0))
>> +#define TCG_MB_READ
On 05/31/2016 11:39 AM, Pranith Kumar wrote:
+* Memory Barrier support
+
+* mb <$arg>
Document what $arg should be.
+Generate a target memory barrier instruction to ensure memory ordering as being
+enforced by a corresponding guest memory barrier instruction. The ordering
+enforced by
This commit introduces the TCGOpcode for memory barrier instruction.
This opcode takes an argument which is the type of memory barrier
which should be generated.
Signed-off-by: Pranith Kumar
Signed-off-by: Richard Henderson
---
tcg/README| 17 +
tcg/tcg-op.c | 6 ++
t
34 matches
Mail list logo
