On Tue, Oct 28, 2014 at 5:22 AM, Yangfei (Felix) wrote:
> 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.
I have committed this patch as attached. I made a couple of minor
cleanups, plus some
> On Thu, Oct 23, 2014 at 11:51 PM, Yangfei (Felix)
> 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
On Thu, Oct 23, 2014 at 11:51 PM, Yangfei (Felix) 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
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.
>
> On T
On Thu, Oct 23, 2014 at 11:40 PM, Yangfei (Felix) wrote:
> 1. The original xtensa port never generates "loop" instruction at all.
> 2. A port doesn't need to implement hwloop_pattern_reg hook if it has no
> zero-cost loop instruction.
>
> Is that clear?
We are talking in circles. I understand ve
1. The original xtensa port never generates "loop" instruction at all.
2. A port doesn't need to implement hwloop_pattern_reg hook if it has no
zero-cost loop instruction.
Is that clear?
>
> I mean without your patch at all.
>
> On Thu, Oct 23, 2014 at 11:30 PM, Yangfei (Felix)
> wrote:
> >>
I mean without your patch at all.
On Thu, Oct 23, 2014 at 11:30 PM, Yangfei (Felix) wrote:
>>
>> On Thu, Oct 23, 2014 at 9:12 PM, Yangfei (Felix)
>> wrote:
>> >> Here the key point is we need a general purpose register for the "loop"
>> >> instruction.
>>
>> So the question to ask here is, "How
>
> On Thu, Oct 23, 2014 at 9:12 PM, Yangfei (Felix)
> wrote:
> >> Here the key point is we need a general purpose register for the "loop"
> >> instruction.
>
> So the question to ask here is, "How does this work today, without loop
> instructions?" Somehow--even when it has been spilled--a bra
On Thu, Oct 23, 2014 at 9:12 PM, Yangfei (Felix) wrote:
>> Here the key point is we need a general purpose register for the "loop"
>> instruction.
So the question to ask here is, "How does this work today, without
loop instructions?" Somehow--even when it has been spilled--a branch
instruction ca
> > On Tue, Oct 21, 2014 at 7:20 PM, Yangfei (Felix)
> wrote:
> > > If the tripcount spill issue is not handled in the pattern, ICE may
> > > happen then.
> > > Here reload is trying to spill pseudo 173, but a memory operand is
> > > not allowed
> > in zero_cost_loop_end pattern.
> > > And this i
> On Tue, Oct 21, 2014 at 7:20 PM, Yangfei (Felix)
> wrote:
> > If the tripcount spill issue is not handled in the pattern, ICE may happen
> > then.
> > Here reload is trying to spill pseudo 173, but a memory operand is not
> > allowed
> in zero_cost_loop_end pattern.
> > And this is what I am
On Tue, Oct 21, 2014 at 7:20 PM, Yangfei (Felix) wrote:
> If the tripcount spill issue is not handled in the pattern, ICE may happen
> then.
> Here reload is trying to spill pseudo 173, but a memory operand is not
> allowed in zero_cost_loop_end pattern.
> And this is what I am trying to solve.
If the tripcount spill issue is not handled in the pattern, ICE may happen
then.
Here reload is trying to spill pseudo 173, but a memory operand is not allowed
in zero_cost_loop_end pattern.
And this is what I am trying to solve.
pr44023.c:48:1: error: unable to generate reloads for:
}
^
(j
Hi Sterling,
Attached please find the testcase for the spill issue. Try it out with the
patch :-)
>
> On Wed, Oct 15, 2014 at 7:10 PM, Yangfei (Felix)
> wrote:
> > Hi Sterling,
> >
> > Since the patch is delayed for a long time, I'm kind of pushing it.
> > Sorry for
> that.
> > Y
On Wed, Oct 15, 2014 at 7:10 PM, Yangfei (Felix) wrote:
> Hi Sterling,
>
> Since the patch is delayed for a long time, I'm kind of pushing it. Sorry
> for that.
> Yeah, you are right. We have some performance issue here as GCC may use
> one more general register in some cases with this p
Hi Sterling,
Since the patch is delayed for a long time, I'm kind of pushing it. Sorry
for that.
Yeah, you are right. We have some performance issue here as GCC may use one
more general register in some cases with this patch.
Take the following arraysum testcase for example. In dol
On Tue, Oct 14, 2014 at 8:39 AM, Felix Yang wrote:
> PING？
> Cheers,
> Felix
Felix,
This isn't my day job, 24-hour pings are unproductive.
You shouldn't need to worry about the trip count register getting
spilled. It makes no difference whatsoever to how the loop
operates--the trip count is dea
PING？
Cheers,
Felix
On Tue, Oct 14, 2014 at 12:30 AM, Felix Yang wrote:
> Thanks for the comments.
>
> The patch checked the usage of teh trip count register, making sure
> that it is not used in the loop body other than the doloop_end or
> lives past the doloop_end instruction, as the following
Thanks for the comments.
The patch checked the usage of teh trip count register, making sure
that it is not used in the loop body other than the doloop_end or
lives past the doloop_end instruction, as the following code snippet
shows:
+ /* Scan all the blocks to make sure they don't use iter_reg
On Fri, Oct 10, 2014 at 6:59 AM, Felix Yang wrote:
> Hi Sterling,
>
> I made some improvement to the patch. Two changes:
> 1. TARGET_LOOPS is now used as a condition of the doloop related
> patterns, which is more elegant.
Fine.
> 2. As the trip count register of the zero-cost loop m
Hi Sterling,
I made some improvement to the patch. Two changes:
1. TARGET_LOOPS is now used as a condition of the doloop related
patterns, which is more elegant.
2. As the trip count register of the zero-cost loop maybe
potentially spilled, we need to change the patterns in order to ha
Hello Sterling,
My paper work with the FSF has finished and we can now move
forward with this patch :-)
I rebased the patch on the latest trunk. Attached please find
version 3 of the patch.
And the enclosed patch also includes the two points pointed by
you, do you like it?
Make
On Thu, Jan 9, 2014 at 7:48 PM, Yangfei (Felix) wrote:
> And here is the xtensa configuration tested (include/xtensa-config.h):
>
> #define XCHAL_HAVE_BE 0
> #define XCHAL_HAVE_LOOPS1
Hi Felix,
I like this patch, and expect I will approve it. However, I would like
you
And here is the xtensa configuration tested (include/xtensa-config.h):
#define XCHAL_HAVE_BE 0
#define XCHAL_HAVE_LOOPS1
>
> Hi Sterling,
>
> Please note that version 2 of the patch is for gcc trunk, not for
> gcc-4.8 branch.
> Since the doloop_end pattern fo
Hi Sterling,
Please note that version 2 of the patch is for gcc trunk, not for
gcc-4.8 branch.
Since the doloop_end pattern format has changed, this patch need
small adaptation in order for it to work on gcc-4.8.
Although I test it on gcc-4.8, I think the testing result still
holds fo
Hi Sterling,
Attached please find version 2 of the patch.
I applied this updated patch (with small adaptations) to gcc-4.8.2
and carried out some tests.
I can execute the testcases in a simulator, which support
zero-overhead looping instructions.
First of all, I can successfully
On Wed, Jan 8, 2014 at 8:27 AM, Felix Yang wrote:
> Hi Sterling,
>
> This patch implements zero-overhead looping for xtensa backend using
> hw-doloop facility.
> If OK for trunk, please apply it for me. Thanks.
Hi Felix,
I last worked on zero-overhead loops for Xtensa in the gcc 4.3
timefram
Hi Sterling,
This patch implements zero-overhead looping for xtensa backend using
hw-doloop facility.
If OK for trunk, please apply it for me. Thanks.
Index: gcc/ChangeLog
===
--- gcc/ChangeLog(revision 206431)
+++ gcc/Chang
28 matches
Mail list logo
