On Mon, Nov 24, 2014 at 10:28 PM, James Greenhalgh
wrote:
> On Fri, Nov 14, 2014 at 02:43:12AM +, Bin.Cheng wrote:
>> On Fri, Nov 7, 2014 at 7:13 AM, Jeff Law wrote:
>> > On 11/05/14 02:30, Bin.Cheng wrote:
>> >> Thanks very much for reviewing. I refined the patch according to your
>> >> com
On Fri, Nov 14, 2014 at 02:43:12AM +, Bin.Cheng wrote:
> On Fri, Nov 7, 2014 at 7:13 AM, Jeff Law 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 dependency
On Fri, Nov 7, 2014 at 7:13 AM, Jeff Law 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 re
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 won'
On Sat, Nov 1, 2014 at 4:29 AM, Jeff Law wrote:
> On 09/30/14 03:22, Bin Cheng wrote:
>
>>
>> 2014-09-30 Bin Cheng
>> Mike Stump
>>
>> * timevar.def (TV_SCHED_FUSION): New time var.
>> * passes.def (pass_sched_fusion): New pass.
>> * config/arm/arm.c (TARGET_SC
On 09/30/14 03:22, Bin Cheng wrote:
2014-09-30 Bin Cheng
Mike Stump
* timevar.def (TV_SCHED_FUSION): New time var.
* passes.def (pass_sched_fusion): New pass.
* config/arm/arm.c (TARGET_SCHED_FUSION_PRIORITY): New.
(extract_base_offset_in_addr, fusi
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 pattern
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
Thanks for giving it a try.
On Fri, Oct 31, 2014 at 3:43 AM, Jeff Law 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.
>
> Fundamenta
On Oct 30, 2014, at 12:43 PM, Jeff Law 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.
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 i
On Sat, Oct 11, 2014 at 5:13 AM, Jeff Law 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 nothing
On Oct 10, 2014, at 8:32 PM, Bin.Cheng 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 my versio
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 wrote:
> [ 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, t
[ 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 wrote:
> So, some questions. Let's assume I've got 3 kinds of insns. A B & C.
>
> I can fuse AB or AC, but
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
On Oct 7, 2014, at 10:28 PM, Jeff Law 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).
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 w
>> 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 p
On Wed, Oct 8, 2014 at 1:28 PM, Jeff Law wrote:
> On 10/06/14 19:31, Bin.Cheng wrote:
>>
>> On Tue, Oct 7, 2014 at 1:20 AM, Mike Stump wrote:
>>>
>>> On Oct 6, 2014, at 4:32 AM, Richard Biener
>>> wrote:
On Mon, Oct 6, 2014 at 11:57 AM, Bin.Cheng
wrote:
How many merging
On 10/06/14 19:31, Bin.Cheng wrote:
On Tue, Oct 7, 2014 at 1:20 AM, Mike Stump wrote:
On Oct 6, 2014, at 4:32 AM, Richard Biener wrote:
On Mon, Oct 6, 2014 at 11:57 AM, Bin.Cheng wrote:
How many merging opportunities does sched2 undo again? ISTR it
has the tendency of pushing stores down a
On Tue, Oct 7, 2014 at 1:20 AM, Mike Stump wrote:
> On Oct 6, 2014, at 4:32 AM, Richard Biener wrote:
>> On Mon, Oct 6, 2014 at 11:57 AM, Bin.Cheng wrote:
>>
>> How many merging opportunities does sched2 undo again? ISTR it
>> has the tendency of pushing stores down and loads up.
>
> So, the pa
On Oct 6, 2014, at 4:32 AM, Richard Biener wrote:
> On Mon, Oct 6, 2014 at 11:57 AM, Bin.Cheng 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 merging 2 or more loads into 1 load (at least o
On Mon, Oct 6, 2014 at 11:57 AM, Bin.Cheng wrote:
> On Wed, Oct 1, 2014 at 5:06 AM, Mike Stump wrote:
>> On Sep 30, 2014, at 2:22 AM, Bin Cheng wrote:
>>> Then I decided to take one step forward to introduce a generic
>>> instruction fusion infrastructure in GCC, because in essence, load/store
>
On Wed, Oct 1, 2014 at 5:06 AM, Mike Stump wrote:
> On Sep 30, 2014, at 2:22 AM, Bin Cheng 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 fusio
On Sep 30, 2014, at 2:22 AM, Bin Cheng 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 push instruct
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
Mike
27 matches
Mail list logo
