"Juan A. Suarez Romero" writes:
> On Mon, 2016-08-08 at 16:12 +0200, Juan A. Suarez Romero wrote:
>> Hmm... what about the case of exec_size == 4 and writing just a
>> float?
>>
>> I understand in this case we only should mark one word, so the loop
>> should not be 2*inst->regs_written.
>>
>>
On Mon, 2016-08-08 at 16:12 +0200, Juan A. Suarez Romero wrote:
> Hmm... what about the case of exec_size == 4 and writing just a
> float?
>
> I understand in this case we only should mark one word, so the loop
> should not be 2*inst->regs_written.
>
> Note that in the original patch that was t
On Fri, 2016-07-29 at 12:59 -0700, Francisco Jerez wrote:
> | for (unsigned i = 0; i < 2 * inst->regs_written; i++)
> {
> | for (int c = 0; c < 4; c++)
> | result_live[c] |= BITSET_TEST(
> | live, var_from_reg(alloc, inst->ds
On Fri, 2016-07-29 at 12:59 -0700, Francisco Jerez wrote:
> Iago Toral Quiroga writes:
>
> >
> > From: "Juan A. Suarez Romero"
> >
> > Our current data flow analysis does not take into account that
> > channels
> > on 64-bit operands are 64-bit. This is a problem when the same
> > register
> >
Iago Toral Quiroga writes:
> From: "Juan A. Suarez Romero"
>
> Our current data flow analysis does not take into account that channels
> on 64-bit operands are 64-bit. This is a problem when the same register
> is accessed using both 64-bit and 32-bit channels. This is very common
> in operation
This patch should not be so early in the series. It uses the execsize
information in the IR which is not available until patch 38, so it
should really go after that.
Iago
On Tue, 2016-07-19 at 12:40 +0200, Iago Toral Quiroga wrote:
> From: "Juan A. Suarez Romero"
>
> Our current data flow analy
From: "Juan A. Suarez Romero"
Our current data flow analysis does not take into account that channels
on 64-bit operands are 64-bit. This is a problem when the same register
is accessed using both 64-bit and 32-bit channels. This is very common
in operations where we need to access 64-bit data in
