On Wed, Aug 16, 2023 at 4:38 AM Kewen.Lin wrote:
>
> on 2023/8/15 17:13, Richard Sandiford wrote:
> > Richard Biener writes:
> >>> OK, fair enough. So the idea is: see where we end up and then try to
> >>> improve/factor the APIs in a less peephole way?
> >>
> >> Yeah, I think that's the only
on 2023/8/15 17:13, Richard Sandiford wrote:
> Richard Biener writes:
>>> OK, fair enough. So the idea is: see where we end up and then try to
>>> improve/factor the APIs in a less peephole way?
>>
>> Yeah, I think that's the only good way forward.
>
> OK, no objection from me. Sorry for
on 2023/8/15 20:07, Richard Biener wrote:
> On Tue, Aug 15, 2023 at 1:47 PM Kewen.Lin wrote:
>>
>> on 2023/8/15 15:53, Richard Biener wrote:
>>> On Tue, Aug 15, 2023 at 4:44 AM Kewen.Lin wrote:
on 2023/8/14 22:16, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
On Tue, Aug 15, 2023 at 1:47 PM Kewen.Lin wrote:
>
> on 2023/8/15 15:53, Richard Biener wrote:
> > On Tue, Aug 15, 2023 at 4:44 AM Kewen.Lin wrote:
> >>
> >> on 2023/8/14 22:16, Richard Sandiford wrote:
> >>> "Kewen.Lin" writes:
> Hi Richard,
>
> on 2023/8/14 20:20, Richard
on 2023/8/15 15:53, Richard Biener wrote:
> On Tue, Aug 15, 2023 at 4:44 AM Kewen.Lin wrote:
>>
>> on 2023/8/14 22:16, Richard Sandiford wrote:
>>> "Kewen.Lin" writes:
Hi Richard,
on 2023/8/14 20:20, Richard Sandiford wrote:
> Thanks for the clean-ups. But...
>
>
Richard Biener writes:
>> OK, fair enough. So the idea is: see where we end up and then try to
>> improve/factor the APIs in a less peephole way?
>
> Yeah, I think that's the only good way forward.
OK, no objection from me. Sorry for holding the patch up.
Richard
On Tue, Aug 15, 2023 at 10:44 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Tue, Aug 15, 2023 at 4:44 AM Kewen.Lin wrote:
> >>
> >> on 2023/8/14 22:16, Richard Sandiford wrote:
> >> > No, it was more that 219-142=77, so it seems like a lot of lines
> >> > are being duplicated
Richard Biener writes:
> On Tue, Aug 15, 2023 at 4:44 AM Kewen.Lin wrote:
>>
>> on 2023/8/14 22:16, Richard Sandiford wrote:
>> > No, it was more that 219-142=77, so it seems like a lot of lines
>> > are being duplicated rather than simply being moved. (Unlike for
>> > VMAT_LOAD_STORE_LANES,
On Tue, Aug 15, 2023 at 4:44 AM Kewen.Lin wrote:
>
> on 2023/8/14 22:16, Richard Sandiford wrote:
> > "Kewen.Lin" writes:
> >> Hi Richard,
> >>
> >> on 2023/8/14 20:20, Richard Sandiford wrote:
> >>> Thanks for the clean-ups. But...
> >>>
> >>> "Kewen.Lin" writes:
> Hi,
>
>
on 2023/8/14 22:16, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
>> on 2023/8/14 20:20, Richard Sandiford wrote:
>>> Thanks for the clean-ups. But...
>>>
>>> "Kewen.Lin" writes:
Hi,
Following Richi's suggestion [1], this patch is to move the
handlings on
"Kewen.Lin" writes:
> Hi Richard,
>
> on 2023/8/14 20:20, Richard Sandiford wrote:
>> Thanks for the clean-ups. But...
>>
>> "Kewen.Lin" writes:
>>> Hi,
>>>
>>> Following Richi's suggestion [1], this patch is to move the
>>> handlings on VMAT_GATHER_SCATTER in the final loop nest
>>> of
Hi Richard,
on 2023/8/14 20:20, Richard Sandiford wrote:
> Thanks for the clean-ups. But...
>
> "Kewen.Lin" writes:
>> Hi,
>>
>> Following Richi's suggestion [1], this patch is to move the
>> handlings on VMAT_GATHER_SCATTER in the final loop nest
>> of function vectorizable_load to its own
Thanks for the clean-ups. But...
"Kewen.Lin" writes:
> Hi,
>
> Following Richi's suggestion [1], this patch is to move the
> handlings on VMAT_GATHER_SCATTER in the final loop nest
> of function vectorizable_load to its own loop. Basically
> it duplicates the final loop nest, clean up some
Hi,
Following Richi's suggestion [1], this patch is to move the
handlings on VMAT_GATHER_SCATTER in the final loop nest
of function vectorizable_load to its own loop. Basically
it duplicates the final loop nest, clean up some useless
set up code for the case of VMAT_GATHER_SCATTER, remove some
14 matches
Mail list logo
