Hi!
On Sat, Apr 04, 2020 at 10:21:00AM +1030, Alan Modra wrote:
> I have a series of small patches already, the most significant so far
> being the one that adds the following comment to rs6000_rtx_costs:
>
> "Calls from places like optabs.c:avoid_expensive_constant will come
>here with
On Fri, Apr 03, 2020 at 04:11:32PM -0500, Segher Boessenkool wrote:
> On Fri, Apr 03, 2020 at 10:43:49PM +1030, Alan Modra wrote:
> > Segher probably meant the part I'm working on and haven't posted yet,
> > fixing lots of problems with rs6000_rtx_costs.
>
> I meant PR94393 in fact, but yeah,
On Fri, Apr 03, 2020 at 10:43:49PM +1030, Alan Modra wrote:
> On Fri, Apr 03, 2020 at 02:13:06PM +0800, luoxhu via Gcc-patches wrote:
> > Seems PR94393? Yes, rs6000_emit_set_const calls rs6000_emit_set_long_const
> > for DImode.
> > I tried unsigned long like 0xabcd87654321, 0xabcd87654321
Hi!
On Fri, Apr 03, 2020 at 02:13:06PM +0800, luoxhu wrote:
> Currently 286r.split2 will split "12:%9:DI=0x87654321" to lis+ori by
> rs6000_emit_set_const of define_split, do you mean add new
> define_insn_and_split
> to do the split? Another patch to do this after this one goes upstream in
>
On Fri, Apr 03, 2020 at 02:13:06PM +0800, luoxhu via Gcc-patches wrote:
> Seems PR94393? Yes, rs6000_emit_set_const calls rs6000_emit_set_long_const
> for DImode.
> I tried unsigned long like 0xabcd87654321, 0xabcd87654321 and
> 0xc000ULL,
> All of them are outside of loop even
On 2020/4/3 06:16, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Mar 30, 2020 at 11:59:57AM +0800, luoxhu wrote:
>>> Do we want something later in the RTL pipeline to make "addi"s etc. again?
>
> (This would be a good thing to consider -- maybe a define_insn_and_split
> will work. But see
Hi!
On Mon, Mar 30, 2020 at 11:59:57AM +0800, luoxhu wrote:
> > Do we want something later in the RTL pipeline to make "addi"s etc. again?
(This would be a good thing to consider -- maybe a define_insn_and_split
will work. But see below).
> [PATCH] rs6000: Don't split constant operator add
On 2020/3/27 22:33, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Mar 26, 2020 at 05:06:43AM -0500, luo...@linux.ibm.com wrote:
>> Remove split code from add3 to allow a later pass to split.
>> This allows later logic to hoist out constant load in add instructions.
>> In loop, lis+ori could be
Hi!
On Thu, Mar 26, 2020 at 05:06:43AM -0500, luo...@linux.ibm.com wrote:
> Remove split code from add3 to allow a later pass to split.
> This allows later logic to hoist out constant load in add instructions.
> In loop, lis+ori could be hoisted out to improve performance compared with
> previous
On Thu, 2020-03-26 at 05:06 -0500, luoxhu--- via Gcc-patches wrote:
> From: Xionghu Luo
>
> Remove split code from add3 to allow a later pass to split.
> This allows later logic to hoist out constant load in add
> instructions.
> In loop, lis+ori could be hoisted out to improve performance
From: Xionghu Luo
Remove split code from add3 to allow a later pass to split.
This allows later logic to hoist out constant load in add instructions.
In loop, lis+ori could be hoisted out to improve performance compared with
previous addis+addi (About 15% on typical case), weak point is
one more
11 matches
Mail list logo
