On 07/03/2018 01:11 PM, Martin Liška wrote:
> On 07/03/2018 10:53 AM, Martin Liška wrote:
>> Thank you Jeff.
>>
>> I found some issues when doing build of all targets
>> (contrib/config-list.mk).
>> I'll update patch and test that affected cross-compilers still produce
>> same output.
>
> Hello.
>
On 07/03/2018 10:53 AM, Martin Liška wrote:
Thank you Jeff.
I found some issues when doing build of all targets (contrib/config-list.mk).
I'll update patch and test that affected cross-compilers still produce same
output.
Hello.
I'm done with testing, I bootstrapped and regtested the patch o
On Tue, Jul 03, 2018 at 02:51:27PM +0200, Martin Liška wrote:
> On 07/03/2018 12:58 PM, Segher Boessenkool wrote:
> > On Tue, Jul 03, 2018 at 12:15:48PM +0200, Martin Liška wrote:
> >>> toplev.c already has (in init_alignments):
> >>>
> >>> if (align_jumps_max_skip > align_jumps)
> >>> align_
On 07/03/2018 12:58 PM, Segher Boessenkool wrote:
> On Tue, Jul 03, 2018 at 12:15:48PM +0200, Martin Liška wrote:
>>> toplev.c already has (in init_alignments):
>>>
>>> if (align_jumps_max_skip > align_jumps)
>>> align_jumps_max_skip = align_jumps - 1;
>>
>> I'm rewriting this logic in the pa
On Tue, Jul 03, 2018 at 12:15:48PM +0200, Martin Liška wrote:
> > toplev.c already has (in init_alignments):
> >
> > if (align_jumps_max_skip > align_jumps)
> > align_jumps_max_skip = align_jumps - 1;
>
> I'm rewriting this logic in the patch set. Issue is that
> checking for value of alig
On 07/03/2018 11:55 AM, Segher Boessenkool wrote:
> On Tue, Jul 03, 2018 at 10:53:20AM +0200, Martin Liška wrote:
>> On 06/29/2018 09:04 PM, Jeff Law wrote:
>>> I think this is fine for the trunk.
>>>
>>> jeff
>>
>> Thank you Jeff.
>>
>> I found some issues when doing build of all targets (contrib/
On Tue, Jul 03, 2018 at 10:53:20AM +0200, Martin Liška wrote:
> On 06/29/2018 09:04 PM, Jeff Law wrote:
> > I think this is fine for the trunk.
> >
> > jeff
>
> Thank you Jeff.
>
> I found some issues when doing build of all targets (contrib/config-list.mk).
> I'll update patch and test that aff
On 06/29/2018 09:04 PM, Jeff Law wrote:
> I think this is fine for the trunk.
>
> jeff
Thank you Jeff.
I found some issues when doing build of all targets (contrib/config-list.mk).
I'll update patch and test that affected cross-compilers still produce same
output.
However I noticed one ppc64 i
On 05/21/2018 12:58 PM, marxin wrote:
> gcc/ChangeLog:
>
> 2018-05-25 Denys Vlasenko
> Martin Liska
>
> PR middle-end/66240
> PR target/45996
> PR c/84100
> * common.opt: Rename align options with 'str_' prefix.
> * common/config/i386/i386-common.c (se
gcc/ChangeLog:
2018-05-25 Denys Vlasenko
Martin Liska
PR middle-end/66240
PR target/45996
PR c/84100
* common.opt: Rename align options with 'str_' prefix.
* common/config/i386/i386-common.c (set_malign_value): New
function.
On 04/18/2017 12:30 PM, Denys Vlasenko wrote:
2017-04-18 Denys Vlasenko
* doc/invoke.texi: Update option documentation.
[snip]
The documentation part of this version is OK.
-Sandra
falign-functions=N is too simplistic.
Ingo Molnar ran some tests and it seems that on latest x86 CPUs, 64-byte
alignment
of functions runs fastest (he tried many other possibilites):
this way, after a call CPU can fetch a lot of insns in the first cacheline fill.
However, developers are less tha
On 04/17/2017 09:54 PM, Sandra Loosemore wrote:
@item -falign-functions
@itemx -falign-functions=@var{n}
+@itemx -falign-functions=@var{n},@var{m}
+@itemx -falign-functions=@var{n},@var{m},@var{n2}
+@itemx -falign-functions=@var{n},@var{m},@var{n2},@var{m2}
@opindex falign-functions
Align
On 04/17/2017 09:57 AM, Denys Vlasenko wrote:
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 246948)
+++ gcc/doc/invoke.texi (working copy)
@@ -351,9 +351,11 @@ Objective-C and Objective-C++ Dialects}.
@item Opti
falign-functions=N is too simplistic.
Ingo Molnar ran some tests and it seems that on latest x86 CPUs, 64-byte
alignment
of functions runs fastest (he tried many other possibilites):
this way, after a call CPU can fetch a lot of insns in the first cacheline fill.
However, developers are less tha
falign-functions=N is too simplistic.
Ingo Molnar ran some tests and it seems that on latest x86 CPUs, 64-byte
alignment
of functions runs fastest (he tried many other possibilites):
this way, after a call CPU can fetch a lot of insns in the first cacheline fill.
However, developers are less tha
On 10/06/2016 11:47 AM, Bernd Schmidt wrote:
On 09/30/2016 07:54 PM, Denys Vlasenko wrote:
+struct target_flag_state {
+ /* Each falign-foo can generate up to two levels of alignment:
+ -falign-foo=N,M[,N2,M2] */
+ struct align_flags x_align_loops[2];
+ struct align_flags x_align_jumps[
On 09/30/2016 07:54 PM, Denys Vlasenko wrote:
+struct target_flag_state {
+ /* Each falign-foo can generate up to two levels of alignment:
+ -falign-foo=N,M[,N2,M2] */
+ struct align_flags x_align_loops[2];
+ struct align_flags x_align_jumps[2];
+ struct align_flags x_align_labels[2];
+
falign-functions=N is too simplistic.
Ingo Molnar ran some tests and it seems that on latest x86 CPUs, 64-byte
alignment
of functions runs fastest (he tried many other possibilites):
this way, after a call CPU can fetch a lot of insns in the first cacheline fill.
However, developers are less tha
19 matches
Mail list logo
