On 29/09/2020 14:20, Segher Boessenkool wrote:
> On Tue, Sep 29, 2020 at 11:36:12AM +0100, Alex Coplan wrote:
> > Is the combine change (a canonicalization fix, as described below) OK
> > for trunk in light of this info?
>
> Can you please resend it with correct info and a corresponding commit
> m
On Tue, Sep 29, 2020 at 11:36:12AM +0100, Alex Coplan wrote:
> Is the combine change (a canonicalization fix, as described below) OK
> for trunk in light of this info?
Can you please resend it with correct info and a corresponding commit
message?
Segher
Hi Segher,
Gentle ping.
Is the combine change (a canonicalization fix, as described below) OK
for trunk in light of this info?
On 22/09/2020 17:08, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > Hi Alex,
> >
> > On Tue, Sep 22, 2020 at 08:40:07AM +0100, Alex Coplan wrote:
> >> On 21/
Segher Boessenkool writes:
> Hi Alex,
>
> On Tue, Sep 22, 2020 at 08:40:07AM +0100, Alex Coplan wrote:
>> On 21/09/2020 18:35, Segher Boessenkool wrote:
>> Thanks for doing this testing. The results look good, then: no code size
>> changes and no build regressions.
>
> No *code* changes. I cannot
Hi Alex,
On Tue, Sep 22, 2020 at 08:40:07AM +0100, Alex Coplan wrote:
> On 21/09/2020 18:35, Segher Boessenkool wrote:
> Thanks for doing this testing. The results look good, then: no code size
> changes and no build regressions.
No *code* changes. I cannot test aarch64 likme this.
> > So, ther
Hi Segher,
On 21/09/2020 18:35, Segher Boessenkool wrote:
> Hi!
>
> So, I tested this patch. The test builds Linux for all targets, and the
> number reported here is just binary size (usually a good indicator for
> combine effectiveness). C0 is the unmodified compiler, C1 is with your
> patch.
Hi!
So, I tested this patch. The test builds Linux for all targets, and the
number reported here is just binary size (usually a good indicator for
combine effectiveness). C0 is the unmodified compiler, C1 is with your
patch. A size of 0 means it did not build.
C0C1
Hi Richard, Segher,
On 17/09/2020 08:10, Richard Sandiford wrote:
> Alex Coplan writes:
> > Hi Richard,
> >
> > On 10/09/2020 19:18, Richard Sandiford wrote:
> >> Alex Coplan writes:
> >> > Hello,
> >> >
> >> > Since r11-2903-g6b3034eaba83935d9f6dfb20d2efbdb34b5b00bf introduced a
> >> > canonica
Hi!
On Thu, Sep 17, 2020 at 08:10:22AM +0100, Richard Sandiford wrote:
> Alex Coplan writes:
> The combine parts LGTM otherwise, but Segher should have the
> final say.
I am doubtful this does not regress on many targets.
I'll test it, we'll see :-)
Segher
Alex Coplan writes:
> Hi Richard,
>
> On 10/09/2020 19:18, Richard Sandiford wrote:
>> Alex Coplan writes:
>> > Hello,
>> >
>> > Since r11-2903-g6b3034eaba83935d9f6dfb20d2efbdb34b5b00bf introduced a
>> > canonicalization from mult to shift on address reloads, a missing
>> > pattern in the AArch64
Hi!
On Thu, Sep 10, 2020 at 07:18:01PM +0100, Richard Sandiford wrote:
> It's all a bit unfortunate really. Having different representations
> for shifts inside and outside MEMs is the Second Great RTL Mistake.
Yes... All targets with something that computes shifted addresses (like
in a LEA
Hi Richard,
On 10/09/2020 19:18, Richard Sandiford wrote:
> Alex Coplan writes:
> > Hello,
> >
> > Since r11-2903-g6b3034eaba83935d9f6dfb20d2efbdb34b5b00bf introduced a
> > canonicalization from mult to shift on address reloads, a missing
> > pattern in the AArch64 backend was exposed.
> >
> > In
Alex Coplan writes:
> Hello,
>
> Since r11-2903-g6b3034eaba83935d9f6dfb20d2efbdb34b5b00bf introduced a
> canonicalization from mult to shift on address reloads, a missing
> pattern in the AArch64 backend was exposed.
>
> In particular, we were missing the ashift variant of
> *add__multp2 (this mul
Hello,
Since r11-2903-g6b3034eaba83935d9f6dfb20d2efbdb34b5b00bf introduced a
canonicalization from mult to shift on address reloads, a missing
pattern in the AArch64 backend was exposed.
In particular, we were missing the ashift variant of
*add__multp2 (this mult variant is redundant and was
remo
14 matches
Mail list logo
