On Mon, 10 Jan 2022, Andre Vieira (lists) wrote:
> Hi,
>
> I don't think I ever ended up posting the rebased version on top of the
> epilogue mode patch. So here it is, I think I had a conditional OK if I split
> the epilogue mode patch, but just want to double check this is OK for trunk?
Yes, I
Hi,
I don't think I ever ended up posting the rebased version on top of the
epilogue mode patch. So here it is, I think I had a conditional OK if I
split the epilogue mode patch, but just want to double check this is OK
for trunk?
gcc/ChangeLog:
* tree-vect-loop.c (vect_estimate_mi
On Tue, 30 Nov 2021, Andre Vieira (lists) wrote:
>
> On 25/11/2021 12:46, Richard Biener wrote:
> > Oops, my fault, yes, it does. I would suggest to refactor things so
> > that the mode_i = first_loop_i case is there only once. I also wonder
> > if all the argument about starting at 0 doesn't a
On 25/11/2021 12:46, Richard Biener wrote:
Oops, my fault, yes, it does. I would suggest to refactor things so
that the mode_i = first_loop_i case is there only once. I also wonder
if all the argument about starting at 0 doesn't apply to the
not unrolled LOOP_VINFO_EPIL_USING_PARTIAL_VECTORS_
On Thu, 25 Nov 2021, Andre Vieira (lists) wrote:
>
> On 24/11/2021 11:00, Richard Biener wrote:
> > On Wed, 24 Nov 2021, Andre Vieira (lists) wrote:
> >
> >> On 22/11/2021 12:39, Richard Biener wrote:
> >>> + if (first_loop_vinfo->suggested_unroll_factor > 1)
> >>> +{
> >>> + if (LOOP_V
On 24/11/2021 11:00, Richard Biener wrote:
On Wed, 24 Nov 2021, Andre Vieira (lists) wrote:
On 22/11/2021 12:39, Richard Biener wrote:
+ if (first_loop_vinfo->suggested_unroll_factor > 1)
+{
+ if (LOOP_VINFO_EPIL_USING_PARTIAL_VECTORS_P (first_loop_vinfo))
+ {
+ if (d
On Wed, 24 Nov 2021, Andre Vieira (lists) wrote:
>
> On 22/11/2021 12:39, Richard Biener wrote:
> > + if (first_loop_vinfo->suggested_unroll_factor > 1)
> > +{
> > + if (LOOP_VINFO_EPIL_USING_PARTIAL_VECTORS_P (first_loop_vinfo))
> > + {
> > + if (dump_enabled_p ())
> > +
On 22/11/2021 12:39, Richard Biener wrote:
+ if (first_loop_vinfo->suggested_unroll_factor > 1)
+{
+ if (LOOP_VINFO_EPIL_USING_PARTIAL_VECTORS_P (first_loop_vinfo))
+ {
+ if (dump_enabled_p ())
+ dump_printf_loc (MSG_NOTE, vect_location,
+
On Mon, 22 Nov 2021, Andre Vieira (lists) wrote:
>
> On 12/11/2021 13:12, Richard Biener wrote:
> > On Thu, 11 Nov 2021, Andre Vieira (lists) wrote:
> >
> >> Hi,
> >>
> >> This is the rebased and reworked version of the unroll patch. I wasn't
> >> entirely sure whether I should compare the costs
On 12/11/2021 13:12, Richard Biener wrote:
On Thu, 11 Nov 2021, Andre Vieira (lists) wrote:
Hi,
This is the rebased and reworked version of the unroll patch. I wasn't
entirely sure whether I should compare the costs of the unrolled loop_vinfo
with the original loop_vinfo it was unrolled of.
On Thu, 11 Nov 2021, Andre Vieira (lists) wrote:
> Hi,
>
> This is the rebased and reworked version of the unroll patch. I wasn't
> entirely sure whether I should compare the costs of the unrolled loop_vinfo
> with the original loop_vinfo it was unrolled of. I did now, but I wasn't too
> sure wh
Hi,
This is the rebased and reworked version of the unroll patch. I wasn't
entirely sure whether I should compare the costs of the unrolled
loop_vinfo with the original loop_vinfo it was unrolled of. I did now,
but I wasn't too sure whether it was a good idea to... Any thoughts on
this?
Re
Richard Biener writes:
> That said, the overall flow is OK now, some details about the
> max_vf check and where to compute the unrolled VF needs to be
> fleshed out. And then there's the main analysis loop which,
> frankly, is a mess right now, even before your patch :/
Yeah, the loop is certain
"Andre Vieira (lists)" writes:
> On 15/10/2021 09:48, Richard Biener wrote:
>> On Tue, 12 Oct 2021, Andre Vieira (lists) wrote:
>>
>>> Hi Richi,
>>>
>>> I think this is what you meant, I now hide all the unrolling cost
>>> calculations
>>> in the existing target hooks for costs. I did need to adj
On Wed, 20 Oct 2021, Andre Vieira (lists) wrote:
> On 15/10/2021 09:48, Richard Biener wrote:
> > On Tue, 12 Oct 2021, Andre Vieira (lists) wrote:
> >
> >> Hi Richi,
> >>
> >> I think this is what you meant, I now hide all the unrolling cost
> >> calculations
> >> in the existing target hooks for
On 15/10/2021 09:48, Richard Biener wrote:
On Tue, 12 Oct 2021, Andre Vieira (lists) wrote:
Hi Richi,
I think this is what you meant, I now hide all the unrolling cost calculations
in the existing target hooks for costs. I did need to adjust 'finish_cost' to
take the loop_vinfo so the target's
On Tue, 12 Oct 2021, Andre Vieira (lists) wrote:
> Hi Richi,
>
> I think this is what you meant, I now hide all the unrolling cost calculations
> in the existing target hooks for costs. I did need to adjust 'finish_cost' to
> take the loop_vinfo so the target's implementations are able to set the
Hi Richi,
I think this is what you meant, I now hide all the unrolling cost
calculations in the existing target hooks for costs. I did need to
adjust 'finish_cost' to take the loop_vinfo so the target's
implementations are able to set the newly renamed 'suggested_unroll_factor'.
Also added t
Richard Biener via Gcc-patches writes:
> On Thu, 30 Sep 2021, Andre Vieira (lists) wrote:
>
>> Hi,
>>
>>
>> >> That just forces trying the vector modes we've tried before. Though I
>> >> might
>> >> need to revisit this now I think about it. I'm afraid it might be possible
>> >> for
>> >> this
On Thu, 30 Sep 2021, Andre Vieira (lists) wrote:
> Hi,
>
>
> >> That just forces trying the vector modes we've tried before. Though I might
> >> need to revisit this now I think about it. I'm afraid it might be possible
> >> for
> >> this to generate an epilogue with a vf that is not lower than
Hi,
That just forces trying the vector modes we've tried before. Though I might
need to revisit this now I think about it. I'm afraid it might be possible for
this to generate an epilogue with a vf that is not lower than that of the main
loop, but I'd need to think about this again.
Either way
21 matches
Mail list logo