On Mon, 2016-02-29 at 20:45 -0600, Segher Boessenkool wrote:
> On Mon, Feb 29, 2016 at 11:11:11AM -0800, Richard Henderson wrote:
> > > Where are these canonicalization rules described?
> >
> > swap_commutative_operands_p?
>
> That function never swaps reg+reg, or I don't see it.
commutative_ope
On Mon, Feb 29, 2016 at 11:11:11AM -0800, Richard Henderson wrote:
> >>> If you check for fixed registers as well here, does that work for you?
> >>
> >> Maybe. It prevents canonicalization of reg+fp vs fp+reg, which could well
> >> occur via arithmetic on locally allocated arrays.
> >
> > Where
On 02/26/2016 01:52 PM, Segher Boessenkool wrote:
> On Fri, Feb 26, 2016 at 01:35:10PM -0800, Richard Henderson wrote:
>> On 02/26/2016 01:03 PM, Segher Boessenkool wrote:
>>> On Thu, Feb 25, 2016 at 09:08:32PM -0800, Richard Henderson wrote:
+ /* Perform rematerialization if only all ope
On Fri, Feb 26, 2016 at 01:35:10PM -0800, Richard Henderson wrote:
> On 02/26/2016 01:03 PM, Segher Boessenkool wrote:
> > On Thu, Feb 25, 2016 at 09:08:32PM -0800, Richard Henderson wrote:
> >> + /* Perform rematerialization if only all operands are registers and
> >> + all operations
On Fri, Feb 26, 2016 at 01:10:17PM -0800, Richard Henderson wrote:
> On 02/26/2016 01:01 PM, Segher Boessenkool wrote:
> >> How do you imagine the rs6000 change will regress codegen?
> >
> > Combine of sequences with double-length adds.
>
> What sort of test case are you imagining here? The triv
On 02/26/2016 01:03 PM, Segher Boessenkool wrote:
> On Thu, Feb 25, 2016 at 09:08:32PM -0800, Richard Henderson wrote:
>> + /* Perform rematerialization if only all operands are registers and
>> + all operations are PLUS. */
>> + for (i = 0; i < n_ops; i++)
>> +if (ops[i].neg
On 02/26/2016 01:01 PM, Segher Boessenkool wrote:
>> How do you imagine the rs6000 change will regress codegen?
>
> Combine of sequences with double-length adds.
What sort of test case are you imagining here? The trivial tests I've looked
at have all been optimal (before and after).
> It failed
On Thu, Feb 25, 2016 at 09:08:32PM -0800, Richard Henderson wrote:
> diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
> index 450fa8b..9d55e7b 100644
> --- a/gcc/simplify-rtx.c
> +++ b/gcc/simplify-rtx.c
> @@ -4421,9 +4421,17 @@ simplify_plus_minus (enum rtx_code code, machine_mode
> mode, rtx
On Fri, Feb 26, 2016 at 12:51:10PM -0800, Richard Henderson wrote:
> > What is the rs6000 ICE?
>
> The simplify-rtx.c patch causes (reg:M ca) to get sorted to a different spot
> in
> the (plus (plus r1 r2) r3) chain than the rs6000 backend expects, producing an
> ICE due to an unrecognizable insn
On 02/26/2016 12:41 PM, Segher Boessenkool wrote:
> On Thu, Feb 25, 2016 at 09:08:32PM -0800, Richard Henderson wrote:
>> It's the simplify-rtx.c portion of the patch that fixes the i686 regression.
>>
>> In the PR, Alan raises some good points, but I don't believe that we can
>> address those for
On Thu, Feb 25, 2016 at 09:08:32PM -0800, Richard Henderson wrote:
> It's the simplify-rtx.c portion of the patch that fixes the i686 regression.
>
> In the PR, Alan raises some good points, but I don't believe that we can
> address those for gcc6. A new rtl reassoc optimization that takes loop
On Fri, Feb 26, 2016 at 12:08 AM, Richard Henderson wrote:
> It's the simplify-rtx.c portion of the patch that fixes the i686 regression.
>
> In the PR, Alan raises some good points, but I don't believe that we can
> address those for gcc6. A new rtl reassoc optimization that takes loop
> invaria
It's the simplify-rtx.c portion of the patch that fixes the i686 regression.
In the PR, Alan raises some good points, but I don't believe that we can
address those for gcc6. A new rtl reassoc optimization that takes loop
invariance into account will have to wait.
But we do need to take care
13 matches
Mail list logo
