Hi Robin,
On Thu, Aug 29, 2019 at 11:08:11AM +0200, Robin Dapp wrote:
> >> PR37451. Not clear what target that regressed on, btw.
> >
> > And PR55190 and PR67288 and probably more.
>
> Thanks for finding those. So the hope is to get this fixed or rather
> move towards a fix with the patch seri
>> PR37451. Not clear what target that regressed on, btw.
>
> And PR55190 and PR67288 and probably more.
Thanks for finding those. So the hope is to get this fixed or rather
move towards a fix with the patch series that's currently reviewed which
injects some doloop knowledge into ivopts?
As s
On Wed, Aug 28, 2019 at 02:05:58AM -0500, Segher Boessenkool wrote:
> On Tue, Aug 27, 2019 at 05:09:52AM -0500, Segher Boessenkool wrote:
> > On Tue, Aug 27, 2019 at 11:12:32AM +0200, Robin Dapp wrote:
> > > as announced in the wrapped-binop gimple patch mail, on s390 we still
> > > emit odd code i
On Tue, Aug 27, 2019 at 05:09:52AM -0500, Segher Boessenkool wrote:
> On Tue, Aug 27, 2019 at 11:12:32AM +0200, Robin Dapp wrote:
> > as announced in the wrapped-binop gimple patch mail, on s390 we still
> > emit odd code in front of loops:
>
> >aghi%r1,-8
> >srlg%r1,%r1,3
> >a
On Tue, Aug 27, 2019 at 11:12:32AM +0200, Robin Dapp wrote:
> as announced in the wrapped-binop gimple patch mail, on s390 we still
> emit odd code in front of loops:
>aghi%r1,-8
>srlg%r1,%r1,3
>aghi%r1,1
This is done like this because %r1 might be 0.
We see this same pro
Hi,
as announced in the wrapped-binop gimple patch mail, on s390 we still
emit odd code in front of loops:
void v1 (unsigned long *in, unsigned long *out, unsigned int n)
{
int i;
for (i = 0; i < n; i++)
{
out[i] = in[i];
}
}
-->
aghi%r1,-8
srlg%r1,
