On 15/07/2015 12:14, Aurelien Jarno wrote:
> I think for 2.4 we should go with the ADDR32 way, using the following
> kind of patch. It works when %gs is in use, but has to be extended when
> it's not in use. The idea is that qemu_ld/st should behave like other
> 32-bit ops, that is ignore the hig
On 2015-07-15 12:14, Aurelien Jarno wrote:
> On 2015-07-15 11:02, Richard Henderson wrote:
> > On 07/15/2015 09:06 AM, Aurelien Jarno wrote:
> > >On 2015-07-15 09:31, Paolo Bonzini wrote:
> > >>Ok, I see your point. If you put it like this :) the fault definitely
> > >>lies in the backends. What
On 2015-07-15 11:02, Richard Henderson wrote:
> On 07/15/2015 09:06 AM, Aurelien Jarno wrote:
> >On 2015-07-15 09:31, Paolo Bonzini wrote:
> >>Ok, I see your point. If you put it like this :) the fault definitely
> >>lies in the backends. What I'm proposing would be in a new
> >>tcg_reg_alloc_tru
On 07/15/2015 09:06 AM, Aurelien Jarno wrote:
On 2015-07-15 09:31, Paolo Bonzini wrote:
Ok, I see your point. If you put it like this :) the fault definitely
lies in the backends. What I'm proposing would be in a new
tcg_reg_alloc_trunc function, and it would require implementing a
non-noop tr
On 07/14/2015 05:38 PM, Leon Alrae wrote:
There seems to be an issue when trying to keep a pointer in bottom 32-bits
of a 64-bit floating point register. Load and store instructions accessing
this address for some reason use the whole 64-bit content of floating point
register rather than truncate
On 2015-07-15 09:31, Paolo Bonzini wrote:
> Ok, I see your point. If you put it like this :) the fault definitely
> lies in the backends. What I'm proposing would be in a new
> tcg_reg_alloc_trunc function, and it would require implementing a
> non-noop trunc.
Why not reusing the existing trunc_
On 15/07/2015 00:09, Aurelien Jarno wrote:
>> > 2) 64-bit processors that have loads with 32-bit addresses.
>> >
>> >=> qemu_ld/qemu_st can use 32-bit addresses to do the
>> > truncation
>> >
>> >aarch64, I think, falls under this group
> I don't think that works. We don't want to
On 2015-07-14 22:56, Paolo Bonzini wrote:
>
>
> On 14/07/2015 20:37, Aurelien Jarno wrote:
> >> >
> >> > I certainly don't have a global view, so much that I didn't think at
> >> > all of the optimizer... Instead, it looks to me like a bug in the
> >> > register allocator. In particular this
On 14/07/2015 20:37, Aurelien Jarno wrote:
>> >
>> > I certainly don't have a global view, so much that I didn't think at
>> > all of the optimizer... Instead, it looks to me like a bug in the
>> > register allocator. In particular this code in tcg_reg_alloc_mov:
> That's exactly my point whe
On 2015-07-14 20:20, Paolo Bonzini wrote:
>
>
> On 14/07/2015 19:09, Aurelien Jarno wrote:
> > On 2015-07-14 17:38, Leon Alrae wrote:
> >> There seems to be an issue when trying to keep a pointer in bottom 32-bits
> >> of a 64-bit floating point register. Load and store instructions accessing
> >
On 14/07/2015 19:09, Aurelien Jarno wrote:
> On 2015-07-14 17:38, Leon Alrae wrote:
>> There seems to be an issue when trying to keep a pointer in bottom 32-bits
>> of a 64-bit floating point register. Load and store instructions accessing
>> this address for some reason use the whole 64-bit cont
On 2015-07-14 17:38, Leon Alrae wrote:
> There seems to be an issue when trying to keep a pointer in bottom 32-bits
> of a 64-bit floating point register. Load and store instructions accessing
> this address for some reason use the whole 64-bit content of floating point
> register rather than trunc
There seems to be an issue when trying to keep a pointer in bottom 32-bits
of a 64-bit floating point register. Load and store instructions accessing
this address for some reason use the whole 64-bit content of floating point
register rather than truncated 32-bit value. The following load uses
inco
13 matches
Mail list logo
