A somewhat old "issue report" pointed me to the code generated for a 4-fold
manually unrolled version of the following loop:
> while (++len != len_limit) /* this is loop */
> if (pb[len] != cur[len])
> break
On Tue, Jul 17, 2018 at 2:08 AM, Kelvin Nilsen wrote:
> Thanks for looking at this for me. In simplifying the test case for a bug
> report, I've narrowed the "problem" to integer overflow considerations. My
> len variable is declared int, and the target has 64-bit pointers. I'm
> gathering t
On Sat, Jul 21, 2018 at 3:28 AM Bin.Cheng wrote:
>
> On Tue, Jul 17, 2018 at 2:08 AM, Kelvin Nilsen wrote:
> > Thanks for looking at this for me. In simplifying the test case for a bug
> > report, I've narrowed the "problem" to integer overflow considerations. My
> > len variable is declared
On Fri, Jul 13, 2018 at 12:05 AM Kelvin Nilsen wrote:
>
> A somewhat old "issue report" pointed me to the code generated for a 4-fold
> manually unrolled version of the following loop:
>
> > while (++len != len_limit) /* this is loop */
> > if (
On Fri, Jul 13, 2018 at 6:04 AM, Kelvin Nilsen wrote:
> A somewhat old "issue report" pointed me to the code generated for a 4-fold
> manually unrolled version of the following loop:
>
>> while (++len != len_limit) /* this is loop */
>> if (pb[l
Thanks for looking at this for me. In simplifying the test case for a bug
report, I've narrowed the "problem" to integer overflow considerations. My len
variable is declared int, and the target has 64-bit pointers. I'm gathering
that the "manual transformation" I quoted below is not considere