)
> shrpd %r26,%r26,4,%r28
>
>
> I'm guessing this is very similar to what you were thinking (or what I
> described previously).
>
> Many thanks again for trying out these patches/suggestions for me.
>
> Best regards,
> Roger
> --
>
> -Origin
On Thu, Aug 27, 2020 at 9:17 AM Roger Sayle wrote:
>
>
> >On 2020-08-26 5:23 p.m., Roger Sayle wrote:
> >> These more accurate target rtx_costs are used by the
> >> gimple-ssa-strength-reduction.c (via a call to mult_by_coeff_cost) to
> >> decide whether applying strength reduction would be profit
>On 2020-08-26 5:23 p.m., Roger Sayle wrote:
>> These more accurate target rtx_costs are used by the
>> gimple-ssa-strength-reduction.c (via a call to mult_by_coeff_cost) to
>> decide whether applying strength reduction would be profitable. This test
>> case, slsr-13.c, assumes that two multi
On 2020-08-26 5:23 p.m., Roger Sayle wrote:
> These more accurate target rtx_costs are used by the
> gimple-ssa-strength-reduction.c
> (via a call to mult_by_coeff_cost) to decide whether applying strength
> reduction would
> be profitable. This test case, slsr-13.c, assumes that two multiplicat
On Wed, 2020-08-26 at 22:23 +0100, Roger Sayle wrote:
> The failure of slsr-13.c is not caused by the patchh3.txt, but the previous
> patchh2.txt
> that's now on mainline and the gcc-10 branch. That change provided more
> accurate
> rtx_costs for hppa, and solved the performance problems with sy
Message-
From: John David Anglin
Sent: 26 August 2020 21:34
To: l...@redhat.com; Roger Sayle ; 'GCC Patches'
Subject: Re: [PATCH] hppa: Improve expansion of ashldi3 when !TARGET_64BIT
On 2020-08-26 4:08 p.m., Jeff Law wrote:
> It 3-stages, but trips:
> Tests that now fail,
On 2020-08-26 4:08 p.m., Jeff Law wrote:
> It 3-stages, but trips:
> Tests that now fail, but worked before (5 tests):
>
> gcc.dg/tree-ssa/slsr-13.c scan-tree-dump-times optimized " \\* 4" 2
> gcc.dg/tree-ssa/slsr-13.c scan-tree-dump-times optimized " \\* 4" 2
> gcc.dg/tree-ssa/slsr-13.c scan-tree-
On Sun, 2020-08-23 at 00:24 +0100, Roger Sayle wrote:
> Hi Dave,
> I actually think using plus_xor_ior operator is useful. It means that if
> combine,
> inlining or some other RTL simplification generates these variants, these
> forms
> will still be recognized by the backend. It's more typing,
On 2020-08-25 10:05 a.m., Jeff Law wrote:
> On Sat, 2020-08-22 at 09:52 +0100, Roger Sayle wrote:
>> Hi Dave,
>>
>> It's great to hear from you. It's been a long while.
>>
>> Sorry, doh! yes, there's a mistake in my patch (that I introduced when I
>> renumbered
>> the operands in the shd's define_
On Sat, 2020-08-22 at 09:52 +0100, Roger Sayle wrote:
> Hi Dave,
>
> It's great to hear from you. It's been a long while.
>
> Sorry, doh! yes, there's a mistake in my patch (that I introduced when I
> renumbered
> the operands in the shd's define_expand to be the more logical 0, 1, 2, 3,
> then
On Fri, 2020-08-21 at 13:53 +0100, Roger Sayle wrote:
> This patch improves the code generated on PA-RISC for DImode
> (double word) left shifts by small constants (1-31). This target
> has a very cool shd instruction that can be recognized by combine
> for simple shifts, but relying on combine is
22 August 2020 23:09
To: Roger Sayle ; 'GCC Patches'
Cc: 'Jeff Law'
Subject: Re: [PATCH] hppa: Improve expansion of ashldi3 when !TARGET_64BIT
On 2020-08-22 12:01 p.m., Roger Sayle wrote:
> I suspect that the issue with the 64-bit patterns is that the second
>
On 2020-08-22 12:01 p.m., Roger Sayle wrote:
> I suspect that the issue with the 64-bit patterns is that the second variant
> of
> pa.md's define_insn "shrpdi4" is unlikely ever to match as (minus:DI
> (const_int 64) x)
> is never "canonical" when x is itself a CONST_INT. Splitting this
> define_
ear from you. It's been a long while.
>
> Sorry, doh! yes, there's a mistake in my patch (that I introduced when
> I renumbered the operands in the shd's define_expand to be the more
> logical 0, 1, 2, 3, then 4).
> Sorry for the inconvenience [due to my lack of famili
On 2020-08-22 4:52 a.m., Roger Sayle wrote:
> Hi Dave,
>
> It's great to hear from you. It's been a long while.
>
> Sorry, doh! yes, there's a mistake in my patch (that I introduced when I
> renumbered
> the operands in the shd's define_expand to be the more l
eff Law'
Subject: Re: [PATCH] hppa: Improve expansion of ashldi3 when !TARGET_64BIT
Hi Roger,
On 2020-08-21 8:53 a.m., Roger Sayle wrote:
> I was wondering whether Dave or Jeff (or someone else with access to
> real hardware) might "spin" this patch for me?
This may be
Hi Roger,
On 2020-08-21 8:53 a.m., Roger Sayle wrote:
> I was wondering whether Dave or Jeff (or someone else with access
> to real hardware) might "spin" this patch for me?
This may be totally unrelated to this patch but I hit this error in stage2
testing your change:
build/genattrtab ../../gcc/
17 matches
Mail list logo
