This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add zero-overhead looping for xtensa backend
- From: "Yangfei (Felix)" <felix dot yang at huawei dot com>
- To: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "augustine dot sterling at gmail dot com" <augustine dot sterling at gmail dot com>, Andrew Pinski <pinskia at gmail dot com>
- Cc: Felix Yang <fei dot yang0953 at gmail dot com>
- Date: Tue, 28 Oct 2014 12:22:08 +0000
- Subject: Re: [PATCH] Add zero-overhead looping for xtensa backend
- Authentication-results: sourceware.org; auth=none
- References: <CAFc0fxw_SrT8c5y=Ly+X98UhN5_P1bAjMg3n0K06fxAv0ioebg at mail dot gmail dot com> <CAGSvup-V3h1EoZ3D31BEc7Gq0F=YEYJD1GmH+_UipVjNCe=HyQ at mail dot gmail dot com> <CAFc0fxzHg4OktbyTy9341Joubf+A6E3XRj-oCS8WzgVp4pw9mw at mail dot gmail dot com> <CAFc0fxwh7Ey2XFRpbSVNQpQ7RUwcQgGCYHMFB=Yo=6ci261prQ at mail dot gmail dot com> <DA41BE1DDCA941489001C7FBD7A8820E54A354E4 at szxema507-mbx dot china dot huawei dot com> <CAGSvup9qUfTfYOm6FyUcDFeKp4dJtFMjWaC+XnjT6Ca+OqYguA at mail dot gmail dot com> <CAFc0fxxXWa603e0r29WjkSGN7T5JAQ5WZq6iKW46zfvWhou7Dw at mail dot gmail dot com> <CAFc0fxwXVkSf0---P42kdXWR7ibr02uOaiiz8L9Kc=fHTxWY1w at mail dot gmail dot com> <CAGSvup9EP3Vy5f+G_jCKMHPG7t5k6+JZZxE+=HAetXYEusYOeg at mail dot gmail dot com> <CAFc0fxyWfZdiLA7NxK2Zhj5bkdbSg9UOsVVHs5yOp5zSj3Kx0g at mail dot gmail dot com> <CAFc0fxxtvgu39njZ76HAZwgExn7Q+60ycqR+6+toS=+JwaMe+g at mail dot gmail dot com> <CAGSvup-Zd462JYy5kWPn46w28zYajzuaF7YcMS0-7ddyLHx+LQ at mail dot gmail dot com> <DA41BE1DDCA941489001C7FBD7A8820E555490E3 at szxema507-mbx dot china dot huawei dot com> <CAGSvup9g0Wu1JNRVF-GOVJPYiM9wj3s5xsHcug=Bt4-_+uFv8g at mail dot gmail dot com> < DA41BE1DDCA941489001C7FBD7A8820E5554B367 at szxema507-mbx dot china dot huawei dot com> <CAGSvup8Mq9G3EaAWb6r1E8-FntBjVqtkfVqzGLnS5Xg8si2AhQ at mail dot gmail dot com> <DA41BE1DDCA941489001C7FBD7A8820E5554BB0E at szxema507-mbx dot china dot huawei dot com> <CAGSvup_O+c4n6rWFgitQ8=jC7vEuqcZNday_JKHjU=ox16GEpA at mail dot gmail dot com> <DA41BE1DDCA941489001C7FBD7A8820E5554BB60 at szxema507-mbx dot china dot huawei dot com> <CAGSvup9yzkQCV_TaByLfvFLmqjVhy3+yhjUBDvAG3WJmnMuA4Q at mail dot gmail dot com> <DA41BE1DDCA941489001C7FBD7A8820E5554BB72 at szxema507-mbx dot china dot huawei dot com> <CAGSvup_cpVBXLTPQdhZQeSAGnSdMCAddA1DkYh=CZdKCQjkrgw at mail dot gmail dot com> <DA41BE1DDCA941489001C7FBD7A8820E5554BB89 at szxema507-mbx dot china dot huawei dot com> <CA+=Sn1n3QjrwZ7TacSVheLsVoF8TbFoO614ku+bbq3JFfspOKw at mail dot gmail dot com>
> On Thu, Oct 23, 2014 at 11:51 PM, Yangfei (Felix) <felix.yang@huawei.com>
> wrote:
> > Thanks for the explanation. I think I am clear about what you are thinking now.
> > That's an interesting question. I am not sure about reason why GCC's reload
> cannot handle a doloop_end insn.
> > I guess maybe the doloop_end pattern is special? I mean it's a branch insn in a
> parallel form.
>
>
> No it is not special. Just jump are never handled by reload. I thought this was
> documented somewhere also. Basically the main issue with jumps is where
> does the reload value go which side of the jump?
>
> Thanks,
> Andrew
>
Hi Sterling,
How do you think about this issue?
As c6x/bfin port handles this the same way, is it OK for the patch to be applied?
Thanks.