Hi!
On Tue, Jul 28, 2020 at 07:55:58PM +0100, Andrea Corallo wrote:
> > [ Btw, the mailing list archive will not show your attachments (just lets
> > me download them); naming the files *.txt probably works, but you can
> > also use a sane mime type (like, text/plain) ].
>
> [ Sure can do it np,
Segher Boessenkool writes:
> Hi!
Hi Segher,
> [ Btw, the mailing list archive will not show your attachments (just lets
> me download them); naming the files *.txt probably works, but you can
> also use a sane mime type (like, text/plain) ].
[ Sure can do it np, I'm just less sure if
Hi!
[ Btw, the mailing list archive will not show your attachments (just lets
me download them); naming the files *.txt probably works, but you can
also use a sane mime type (like, text/plain) ].
On Wed, Jul 22, 2020 at 12:09:08PM +0200, Andrea Corallo wrote:
> this second patch implements the
Segher Boessenkool writes:
> Hi!
>
> On Fri, Jul 24, 2020 at 09:01:33AM +0200, Andrea Corallo wrote:
>> Segher Boessenkool writes:
>> >> Correct, it's a sliding window only because the real load address is not
>> >> known to the compiler and the algorithm is conservative. I believe we
>> >>
Hi!
On Fri, Jul 24, 2020 at 09:01:33AM +0200, Andrea Corallo wrote:
> Segher Boessenkool writes:
> >> Correct, it's a sliding window only because the real load address is not
> >> known to the compiler and the algorithm is conservative. I believe we
> >> could use ASM_OUTPUT_ALIGN_WITH_NOP if
Segher Boessenkool writes:
> On Wed, Jul 22, 2020 at 09:45:08PM +0200, Andrea Corallo wrote:
>> > Should that actually be a sliding window, or should there actually just
>> > not be more than N branches per aligned block of machine code? Like,
>> > per fetch group.
>> >
>> > Can you not use
On Wed, Jul 22, 2020 at 09:45:08PM +0200, Andrea Corallo wrote:
> > Should that actually be a sliding window, or should there actually just
> > not be more than N branches per aligned block of machine code? Like,
> > per fetch group.
> >
> > Can you not use ASM_OUTPUT_ALIGN_WITH_NOP (or
Segher Boessenkool writes:
> Hi!
>
> On Wed, Jul 22, 2020 at 03:53:34PM +0200, Andrea Corallo wrote:
>> Andrew Pinski writes:
>> > Can you give a simple example of what this patch does?
>>
>> Sure, this pass simply moves a sliding window over the insns trying to
>> make sure that we never have
Hi!
On Wed, Jul 22, 2020 at 03:53:34PM +0200, Andrea Corallo wrote:
> Andrew Pinski writes:
> > Can you give a simple example of what this patch does?
>
> Sure, this pass simply moves a sliding window over the insns trying to
> make sure that we never have more then 'max_branch' branches for
Hi Andrew,
thanks for reviewing I'll work on your comments. Just replying to the
high level questions.
Andrew Pinski writes:
> On Wed, Jul 22, 2020 at 3:10 AM Andrea Corallo wrote:
>>
>> Hi all,
>>
>> this second patch implements the AArch64 specific back-end pass
>> 'branch-dilution'
On Wed, Jul 22, 2020 at 3:10 AM Andrea Corallo wrote:
>
> Hi all,
>
> this second patch implements the AArch64 specific back-end pass
> 'branch-dilution' controllable by the followings command line options:
>
> -mbranch-dilution
>
> --param=aarch64-branch-dilution-granularity={num}
>
>
* gcc.target/aarch64/branch-dilution-on.c: New file.
>From 386b3a3131d5f03a4c9fb8ee47b321009f17fab5 Mon Sep 17 00:00:00 2001
From: Andrea Corallo
Date: Thu, 16 Jul 2020 09:24:33 +0100
Subject: [PATCH 2/2] Aarch64: Add branch diluter pass
gcc/ChangeLog
2020-07-17 Andrea Corall
12 matches
Mail list logo
