On Mon, Nov 24, 2014 at 10:28 PM, James Greenhalgh
james.greenha...@arm.com wrote:
On Fri, Nov 14, 2014 at 02:43:12AM +, Bin.Cheng wrote:
On Fri, Nov 7, 2014 at 7:13 AM, Jeff Law l...@redhat.com wrote:
On 11/05/14 02:30, Bin.Cheng wrote:
Thanks very much for reviewing. I refined the
On Fri, Nov 14, 2014 at 02:43:12AM +, Bin.Cheng wrote:
On Fri, Nov 7, 2014 at 7:13 AM, Jeff Law l...@redhat.com wrote:
On 11/05/14 02:30, Bin.Cheng wrote:
Thanks very much for reviewing. I refined the patch according to your
comments. Also made two small changes: a) skip breaking
On Fri, Nov 7, 2014 at 7:13 AM, Jeff Law l...@redhat.com wrote:
On 11/05/14 02:30, Bin.Cheng wrote:
[ ... ]
rfs_result's signature has changed, I think you need to pass in tmp
tmp2.
You'll need to make that trivial update for all the callers.
Can you make those changes and repost so
On 11/05/14 02:30, Bin.Cheng wrote:
[ ... ]
rfs_result's signature has changed, I think you need to pass in tmp tmp2.
You'll need to make that trivial update for all the callers.
Can you make those changes and repost so that I can look at the docs (I
think the implementation is fine and
On Sat, Nov 1, 2014 at 4:29 AM, Jeff Law l...@redhat.com wrote:
On 09/30/14 03:22, Bin Cheng wrote:
2014-09-30 Bin Chengbin.ch...@arm.com
Mike Stumpmikest...@comcast.net
* timevar.def (TV_SCHED_FUSION): New time var.
* passes.def (pass_sched_fusion): New pass.
On 10/30/14 23:36, Bin.Cheng wrote:
Thanks for giving it a try.
I'm a very hands-on learner, so sometimes the best way for me to
understand a blob of code is poke at it myself a bit.
Anyway, now I just need to get back to the patch for a final review :-)
jeff
On 10/30/14 23:36, Bin.Cheng wrote:
#2 would be the best solution for the case I was pondering, but I don't
think solving that case is terribly important given the processors for which
it was profitable haven't been made for a very long time.
I am thinking if it's possible to introduce a
On 09/30/14 03:22, Bin Cheng wrote:
2014-09-30 Bin Chengbin.ch...@arm.com
Mike Stumpmikest...@comcast.net
* timevar.def (TV_SCHED_FUSION): New time var.
* passes.def (pass_sched_fusion): New pass.
* config/arm/arm.c (TARGET_SCHED_FUSION_PRIORITY): New.
On 10/10/14 21:32, Bin.Cheng wrote:
Mike already gave great answers, here are just some of my thoughts on
the specific questions. See embedded below.
Thanks to both of you for your answers.
Fundamentally, what I see is this scheme requires us to be able to come
up with a key based solely on
On Oct 30, 2014, at 12:43 PM, Jeff Law l...@redhat.com wrote:
Fundamentally, what I see is this scheme requires us to be able to come up
with a key based solely on information in a particular insn. To get fusion
another insn has to have the same or a closely related key.
Right.
Thanks for giving it a try.
On Fri, Oct 31, 2014 at 3:43 AM, Jeff Law l...@redhat.com wrote:
On 10/10/14 21:32, Bin.Cheng wrote:
Mike already gave great answers, here are just some of my thoughts on
the specific questions. See embedded below.
Thanks to both of you for your answers.
On Sat, Oct 11, 2014 at 5:13 AM, Jeff Law l...@redhat.com wrote:
On 09/30/14 03:22, Bin Cheng wrote:
Hi,
many load/store pairs as my old patch. Then I decided to take one step
forward to introduce a generic instruction fusion infrastructure in GCC,
because in essence, load/store pair is
On Oct 10, 2014, at 8:32 PM, Bin.Cheng amker.ch...@gmail.com wrote:
Though I guess if we run fusion + peep2 between sched1 and sched2, that
problem would just resolve itself as we'd have fused AB together into a new
insn and we'd schedule normally with the fused insns and X, Y.
Yes, in
On 09/30/14 03:22, Bin Cheng wrote:
Hi,
many load/store pairs as my old patch. Then I decided to take one step
forward to introduce a generic instruction fusion infrastructure in GCC,
because in essence, load/store pair is nothing different with other
instruction fusion, all these optimizations
[ I’ll give the state of the code that I finished with, Bin’s answers should be
similar to mine, but, if he improved things, they could be better ]
On Oct 10, 2014, at 2:13 PM, Jeff Law l...@redhat.com wrote:
So, some questions. Let's assume I've got 3 kinds of insns. A B C.
I can fuse AB
Mike already gave great answers, here are just some of my thoughts on
the specific questions. See embedded below.
On Sat, Oct 11, 2014 at 7:10 AM, Mike Stump mikest...@comcast.net wrote:
[ I'll give the state of the code that I finished with, Bin's answers should
be similar to mine, but, if
On Oct 7, 2014, at 10:28 PM, Jeff Law l...@redhat.com wrote:
It's certainly advantageous for sched2 to split insns that generate multiple
instructions.
So, on my port, I have a load multiple that is just one instruction, and it is
a single clock cycle (to enque it).
If the port has a splitter to rip apart a douple-word load into single-word
loads, then we'd obviously only want to do that in cases where the
double-word load actually generates 1 assembly instruction.
Or indeed if it is really a performance win. And I think that should
purely be a per
On 10/08/14 04:27, Ramana Radhakrishnan wrote:
If the port has a splitter to rip apart a douple-word load into single-word loads,
then we'd obviously only want to do that in cases where the double-word load
actually generates 1 assembly instruction.
Or indeed if it is really a performance
On 10/06/14 19:31, Bin.Cheng wrote:
On Tue, Oct 7, 2014 at 1:20 AM, Mike Stump mikest...@comcast.net wrote:
On Oct 6, 2014, at 4:32 AM, Richard Biener richard.guent...@gmail.com wrote:
On Mon, Oct 6, 2014 at 11:57 AM, Bin.Cheng amker.ch...@gmail.com wrote:
How many merging opportunities does
On Wed, Oct 8, 2014 at 1:28 PM, Jeff Law l...@redhat.com wrote:
On 10/06/14 19:31, Bin.Cheng wrote:
On Tue, Oct 7, 2014 at 1:20 AM, Mike Stump mikest...@comcast.net wrote:
On Oct 6, 2014, at 4:32 AM, Richard Biener richard.guent...@gmail.com
wrote:
On Mon, Oct 6, 2014 at 11:57 AM,
On Wed, Oct 1, 2014 at 5:06 AM, Mike Stump mikest...@comcast.net wrote:
On Sep 30, 2014, at 2:22 AM, Bin Cheng bin.ch...@arm.com wrote:
Then I decided to take one step forward to introduce a generic
instruction fusion infrastructure in GCC, because in essence, load/store
pair is nothing
On Mon, Oct 6, 2014 at 11:57 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Wed, Oct 1, 2014 at 5:06 AM, Mike Stump mikest...@comcast.net wrote:
On Sep 30, 2014, at 2:22 AM, Bin Cheng bin.ch...@arm.com wrote:
Then I decided to take one step forward to introduce a generic
instruction fusion
On Oct 6, 2014, at 4:32 AM, Richard Biener richard.guent...@gmail.com wrote:
On Mon, Oct 6, 2014 at 11:57 AM, Bin.Cheng amker.ch...@gmail.com wrote:
How many merging opportunities does sched2 undo again? ISTR it
has the tendency of pushing stores down and loads up.
So, the pass works by
On Tue, Oct 7, 2014 at 1:20 AM, Mike Stump mikest...@comcast.net wrote:
On Oct 6, 2014, at 4:32 AM, Richard Biener richard.guent...@gmail.com wrote:
On Mon, Oct 6, 2014 at 11:57 AM, Bin.Cheng amker.ch...@gmail.com wrote:
How many merging opportunities does sched2 undo again? ISTR it
has the
Hi,
Last time I posted the patch pairing consecutive load/store instructions on
ARM, the patch got some review comments. The most important one, as
suggested by Jeff and Mike, is about to do the load/store pairing using
existing scheduling facility. In the initial investigation, I cleared up
On Sep 30, 2014, at 2:22 AM, Bin Cheng bin.ch...@arm.com wrote:
Then I decided to take one step forward to introduce a generic
instruction fusion infrastructure in GCC, because in essence, load/store
pair is nothing different with other instruction fusion, all these
optimizations
want is to
27 matches
Mail list logo
