On Tue, Oct 28, 2014 at 5:22 AM, Yangfei (Felix) felix.y...@huawei.com 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
On Thu, Oct 23, 2014 at 11:51 PM, Yangfei (Felix) felix.y...@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
On Thu, Oct 23, 2014 at 9:12 PM, Yangfei (Felix) felix.y...@huawei.com 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
On Thu, Oct 23, 2014 at 9:12 PM, Yangfei (Felix) felix.y...@huawei.com
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
I mean without your patch at all.
On Thu, Oct 23, 2014 at 11:30 PM, Yangfei (Felix) felix.y...@huawei.com wrote:
On Thu, Oct 23, 2014 at 9:12 PM, Yangfei (Felix) felix.y...@huawei.com
wrote:
Here the key point is we need a general purpose register for the loop
instruction.
So the
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)
On Thu, Oct 23, 2014 at 11:40 PM, Yangfei (Felix) felix.y...@huawei.com 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.
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
On Thu, Oct 23, 2014 at 11:51 PM, Yangfei (Felix) felix.y...@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
On Tue, Oct 21, 2014 at 7:20 PM, Yangfei (Felix) felix.y...@huawei.com 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) felix.y...@huawei.com
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
On Tue, Oct 21, 2014 at 7:20 PM, Yangfei (Felix) felix.y...@huawei.com
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
On Wed, Oct 15, 2014 at 7:10 PM, Yangfei (Felix) felix.y...@huawei.com 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
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) felix.y...@huawei.com
wrote:
Hi Sterling,
Since the patch is delayed for a long time, I'm kind of pushing it.
Sorry for
that.
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:
}
^
On Tue, Oct 14, 2014 at 8:39 AM, Felix Yang fei.yang0...@gmail.com 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
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
PING？
Cheers,
Felix
On Tue, Oct 14, 2014 at 12:30 AM, Felix Yang fei.yang0...@gmail.com 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
On Fri, Oct 10, 2014 at 6:59 AM, Felix Yang fei.yang0...@gmail.com 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
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
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
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?
On Thu, Jan 9, 2014 at 7:48 PM, Yangfei (Felix) felix.y...@huawei.com 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,
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
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
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 format
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)
+++
On Wed, Jan 8, 2014 at 8:27 AM, Felix Yang fei.yang0...@gmail.com 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
28 matches
Mail list logo
