The adjusted vector costs give Falkor a reasonable boost in performance for FP
benchmarks (both CPU2017 and CPU2006) and doesn't change INT benchmarks that
much. About 0.7% for CPU2017 FP and 1.54% for CPU2006 FP.
OK for trunk?
gcc/ChangeLog:
2018-07-25 Luis Machado
* config/aa
Adjust Falkor's register_sextend cost from 4 to 3. This fixes a testsuite
failure in gcc.target/aarch64/extend.c:ldr_sxtw where GCC was generating
a sbfiz instruction rather than a load with sign extension.
No performance changes.
gcc/ChangeLog:
2018-07-25 Luis Machado
* c
Hi Kyrill,
On 07/26/2018 11:34 AM, Kyrill Tkachov wrote:
Hi Luis,
On 25/07/18 19:10, Luis Machado wrote:
The adjusted vector costs give Falkor a reasonable boost in
performance for FP
benchmarks (both CPU2017 and CPU2006) and doesn't change INT
benchmarks that
much. About 0.7% for CP
I've found this stale reference while looking at cp-gimplify.c. tree-gimplify.c
no longer exists and its contents were merged into gimple.c.
Seems obvious enough.
gcc/cp/ChangeLog:
2019-10-16 Luis Machado
* cp-gimplify.c: Fix reference to non-existing tree-gimplify.c file.
S
Hi,
On 08/08/2018 04:54 AM, Siddhesh Poyarekar wrote:
On 08/01/2018 04:23 AM, James Greenhalgh wrote:
On Wed, Jul 25, 2018 at 01:10:34PM -0500, Luis Machado wrote:
The adjusted vector costs give Falkor a reasonable boost in
performance for FP
benchmarks (both CPU2017 and CPU2006) and doesn&#
Hi,
On 08/08/2018 04:46 AM, Siddhesh Poyarekar wrote:
On 08/01/2018 04:24 AM, James Greenhalgh wrote:
OK if this is what is best for your subtarget.
I have pushed this on behalf of Luis since he is on holiday.
Thanks,
Siddhesh
Similarly to the vector cost changes, we've also noticed a non
mething or is this example incorrect and this should either
have a latency of 9 (patch attached) or a different resource utilization
description, say, containing "div*6" instead?
Regards,
Luis
2017-11-09 Luis Machado
PR tree-optimization/82669
diff --git a/gcc/doc/md.texi b/g
On 11/10/2017 08:30 PM, Jim Wilson wrote:
On 11/09/2017 03:44 AM, Luis Machado wrote:
Am i missing something or is this example incorrect and this should
either
have a latency of 9 (patch attached) or a different resource utilization
description, say, containing "div*6" instead?
T
f.
I understand the freeze is happening soon, so it would be great to have this
in before then.
OK?
Thanks,
Luis
2017-11-14 Luis Machado
* config/aarch64/aarch64.c (qdf24xx_prefetch_tune): Remove.
(qdf24xx_tunings): Replace qdf24xx_prefetch_tune with
generic_prefetch_tun
ing?
Thanks,
Luis
2017-11-15 Luis Machado
gcc/
* config/aarch64/aarch64.c
(qdf24xx_prefetch_tune) : Set to -1.
(qdf24xx_tunings) : Set to
tune_params::AUTOPREFETCHER_WEAK.
---
gcc/ChangeLog| 7 +++
gcc/config/aarch64/aarch64.c
On 15 November 2017 at 01:00, Luis Machado wrote:
> > I think the best thing is to leave this tuning structure in place and
> > just change default_opt_level to -1 to disable it at -O3.
> >
> > Thanks,
> > Andrew
> >
>
> Indeed that seems to be more ap
On 11/17/2017 07:25 AM, Kyrill Tkachov wrote:
Hi Luis,
[cc'ing aarch64 maintainers, it's quicker to get review that way]
On 15/11/17 03:00, Luis Machado wrote:
> I think the best thing is to leave this tuning structure in place and
> just change default_opt_level to -1 to d
On 11/17/2017 01:48 PM, James Greenhalgh wrote:
On Wed, Nov 15, 2017 at 03:00:53AM +, Luis Machado wrote:
I think the best thing is to leave this tuning structure in place and
just change default_opt_level to -1 to disable it at -O3.
Thanks,
Andrew
Indeed that seems to be more
const/pure
Volatile operand is not const/pure
scanning: vol.0_10 ={v} i;
Volatile stmt is not const/pure
Seems fairly obvious. OK?
gcc/ChangeLog:
2017-12-01 Luis Machado
* ipa-pure-const.c (check_decl): Add missing newline.
(state_from_flags): Likewise.
---
gcc/ipa
On 12/04/2017 02:01 PM, Jeff Law wrote:
On 12/01/2017 11:42 AM, Luis Machado wrote:
I noticed the debugging output from local-pure-const pass is missing a
newline in a couple places, leading to this:
local analysis of main
scanning: i ={v} 0;
Volatile stmt is not const/pure
aults guarantee no change in behavior
for other targets and architectures.
I've regression-tested and bootstrapped it on aarch64-linux. No problems found.
Ok?
2018-01-22 Luis Machado
Introduce option to control whether the software prefetch pass should
issue prefetch hin
tions.
Luis Machado (2):
Introduce prefetch-minimum stride option
Introduce prefetch-dynamic-strides option.
gcc/config/aarch64/aarch64-protos.h | 6 ++
gcc/config/aarch64/aarch64.c| 24 +++-
gcc/doc/invoke.texi | 25 +
ngs should guarantee no changes for existing targets. Those
are free to tweak the settings as necessary.
No regressions in the testsuite and bootstrapped ok on aarch64-linux.
Ok?
2018-01-22 Luis Machado
Introduce option to limit software prefetching to known constant
strides above
Hi Kyrill,
On 01/23/2018 07:32 AM, Kyrill Tkachov wrote:
Hi Luis,
On 22/01/18 13:46, Luis Machado wrote:
This patch adds a new option to control the minimum stride, for a memory
reference, after which the loop prefetch pass may issue software prefetch
hints for. There are two motivations
Hi,
On 01/23/2018 07:40 AM, Kyrill Tkachov wrote:
Hi Luis,
On 22/01/18 13:46, Luis Machado wrote:
The following patch adds an option to control software prefetching of
memory
references with non-constant/unknown strides.
Currently we prefetch these references if the pass thinks there is
7;d put this up for review. I know we're still not in development
mode yet.
2018-02-02 Luis Machado
gcc/
* config/aarch64/aarch64.md (*ashift_extv_bfiz): New pattern.
* testsuite/gcc.target/aarch64/lsl_asr_sbfiz.c: New test.
---
gcc/config/aarch64/aarch64.md
robably due to the small number of
occurrences.
2018-02-06 Luis Machado
gcc/
* config/aarch64/aarch64.md (*ashift_extv_bfiz): New pattern.
2018-02-06 Luis Machado
gcc/testsuite/
* gcc.target/aarch64/lsl_asr_sbfiz.c: New test.
---
gcc/config/aarch64/
Hi Kyrill,
On 02/08/2018 09:48 AM, Kyrill Tkachov wrote:
Hi Luis,
On 06/02/18 15:04, Luis Machado wrote:
Thanks for the feedback Kyrill. I've adjusted the v2 patch based on your
suggestions and re-tested the changes. Everything is still sane.
Thanks! This looks pretty good to me.
ke it this
update should be trivial enough to go in before development reopens?
Thanks,
Luis
2018-03-01 Luis Machado
* config/aarch64/aarch64.c (qdf24xx_prefetch_tune) : Set
to 512.
---
gcc/config/aarch64/aarch64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
On 03/01/2018 03:45 PM, Luis Machado wrote:
Falkor's prefetch tuning structure still carries the L2 cache size value from
early support code. This patch updates it to match the specifications.
Even though the prefetcher is currently disabled for Falkor, we have a patch
waiting fo
On 03/08/2018 10:30 AM, James Greenhalgh wrote:
On Thu, Mar 01, 2018 at 06:45:21PM +, Luis Machado wrote:
Falkor's prefetch tuning structure still carries the L2 cache size value from
early support code. This patch updates it to match the specifications.
Even though the prefetch
On 05/01/2018 03:30 PM, Jeff Law wrote:
On 01/22/2018 06:46 AM, Luis Machado wrote:
This patch adds a new option to control the minimum stride, for a memory
reference, after which the loop prefetch pass may issue software prefetch
hints for. There are two motivations:
* Make the pass less
On 05/01/2018 03:30 PM, Jeff Law wrote:
On 01/22/2018 06:46 AM, Luis Machado wrote:
The following patch adds an option to control software prefetching of memory
references with non-constant/unknown strides.
Currently we prefetch these references if the pass thinks there is benefit to
doing
Hi,
On 02/08/2018 10:45 AM, Luis Machado wrote:
Hi Kyrill,
On 02/08/2018 09:48 AM, Kyrill Tkachov wrote:
Hi Luis,
On 06/02/18 15:04, Luis Machado wrote:
Thanks for the feedback Kyrill. I've adjusted the v2 patch based on your
suggestions and re-tested the changes. Everything is still
On 05/07/2018 12:15 PM, H.J. Lu wrote:
On Mon, May 7, 2018 at 7:09 AM, Luis Machado wrote:
On 05/01/2018 03:30 PM, Jeff Law wrote:
On 01/22/2018 06:46 AM, Luis Machado wrote:
This patch adds a new option to control the minimum stride, for a memory
reference, after which the loop
Hi Kyrill,
On 05/08/2018 11:09 AM, Kyrill Tkachov wrote:
Hi Luis,
On 07/05/18 15:28, Luis Machado wrote:
Hi,
On 02/08/2018 10:45 AM, Luis Machado wrote:
Hi Kyrill,
On 02/08/2018 09:48 AM, Kyrill Tkachov wrote:
Hi Luis,
On 06/02/18 15:04, Luis Machado wrote:
Thanks for the feedback Kyrill
On 05/09/2018 10:44 AM, Kyrill Tkachov wrote:
On 09/05/18 13:30, Luis Machado wrote:
Hi Kyrill,
On 05/08/2018 11:09 AM, Kyrill Tkachov wrote:
Hi Luis,
On 07/05/18 15:28, Luis Machado wrote:
Hi,
On 02/08/2018 10:45 AM, Luis Machado wrote:
Hi Kyrill,
On 02/08/2018 09:48 AM, Kyrill
On 05/11/2018 06:46 AM, Kyrill Tkachov wrote:
Hi Luis,
On 10/05/18 11:31, Luis Machado wrote:
On 05/09/2018 10:44 AM, Kyrill Tkachov wrote:
On 09/05/18 13:30, Luis Machado wrote:
Hi Kyrill,
On 05/08/2018 11:09 AM, Kyrill Tkachov wrote:
Hi Luis,
On 07/05/18 15:28, Luis Machado wrote:
Hi
e this one a try to see if you can still
reproduce PR85682? I couldn't reproduce it in multiple attempts.
Thanks,
Luis
On 01/22/2018 11:46 AM, Luis Machado wrote:
This patch adds a new option to control the minimum stride, for a memory
reference, after which the loop prefetch pass may
Hi,
On 05/15/2018 06:37 AM, Kyrill Tkachov wrote:
Hi Luis,
On 14/05/18 22:18, Luis Machado wrote:
Hi,
Here's an updated version of the patch (now reverted) that addresses
the previous bootstrap problem (signedness and long long/int conversion).
I've checked that it bootstraps p
On 05/16/2018 06:08 AM, Kyrill Tkachov wrote:
On 15/05/18 12:12, Luis Machado wrote:
Hi,
On 05/15/2018 06:37 AM, Kyrill Tkachov wrote:
Hi Luis,
On 14/05/18 22:18, Luis Machado wrote:
Hi,
Here's an updated version of the patch (now reverted) that addresses
the previous bootstrap pr
Switch from using generic address costs to using Falkor-specific ones, which
give Falkor better results overall.
OK for trunk?
Given this is a Falkor-specific adjustment, would this be an acceptable
backport for GCC 8 as well?
gcc/ChangeLog:
2018-05-22 Luis Machado
* config/aarch64
On 05/16/2018 08:18 AM, Luis Machado wrote:
On 05/16/2018 06:08 AM, Kyrill Tkachov wrote:
On 15/05/18 12:12, Luis Machado wrote:
Hi,
On 05/15/2018 06:37 AM, Kyrill Tkachov wrote:
Hi Luis,
On 14/05/18 22:18, Luis Machado wrote:
Hi,
Here's an updated version of the patch (now rev
On 05/23/2018 05:01 PM, H.J. Lu wrote:
On Tue, May 22, 2018 at 11:55 AM, Luis Machado wrote:
On 05/16/2018 08:18 AM, Luis Machado wrote:
On 05/16/2018 06:08 AM, Kyrill Tkachov wrote:
On 15/05/18 12:12, Luis Machado wrote:
Hi,
On 05/15/2018 06:37 AM, Kyrill Tkachov wrote:
Hi
On 05/23/2018 07:42 PM, H.J. Lu wrote:
On Wed, May 23, 2018 at 3:41 PM, H.J. Lu wrote:
On Wed, May 23, 2018 at 3:35 PM, H.J. Lu wrote:
Sorry. Does the following fix it for i686?
Index: gcc/tree-ssa-loop-prefetch.c
===
--- gc
On 05/23/2018 10:57 PM, Jeff Law wrote:
On 05/23/2018 04:50 PM, Luis Machado wrote:
On 05/23/2018 07:42 PM, H.J. Lu wrote:
On Wed, May 23, 2018 at 3:41 PM, H.J. Lu wrote:
On Wed, May 23, 2018 at 3:35 PM, H.J. Lu wrote:
Sorry. Does the following fix it for i686?
Index: gcc/tree-ssa
On 05/23/2018 12:17 PM, James Greenhalgh wrote:
On Tue, May 22, 2018 at 12:04:38PM -0500, Luis Machado wrote:
Switch from using generic address costs to using Falkor-specific ones, which
give Falkor better results overall.
OK for trunk?
Given this is a Falkor-specific adjustment, would this
On 8/7/23 18:45, Jeff Law wrote:
>
>
> On 8/7/23 04:32, Arsen Arsenović via Gcc-patches wrote:
>> From: Luis Machado
>>
>> With a recent import of gnulib, code has been pulled that tests and enables
>> 64-bit time_t by default on 32-bit hosts that support i
This seems to have broken the builds on AArch64-Linux Ubuntu 18.04.
make[2]: Entering directory 'binutils-gdb-master-bionic/libiberty'
rm -f ./libiberty.a pic/./libiberty.a noasan/./libiberty.a
ar --plugin /usr/lib/gcc/aarch64-linux-gnu/7/liblto_plugin.so rc
./libiberty.a \
./regex.o ./cplus-d
Hi Szabolcs,
Just to confirm, this is a "unwinder debugger hook ABI" change only in
the sense that the generated DWARF will be changed, right? So no further
action from DWARF consumers will be needed. Is that understanding correct?
On 6/5/20 1:51 PM, Szabolcs Nagy wrote:
Mangling, currently
FTR, I'm running into this ICE when attempting to build the Linux Kernel
for arm64.
More specifically:
/repos/linux-arm/kernel/bpf/core.c:1368:1: internal compiler error:
‘global_options’ are modified in local context
1368 | {
| ^
0xc0554b cl_optimization_compare(gcc_options*, gcc_opti
On 6/18/20 12:40 PM, Martin Liška wrote:
I see the following ICE for aarch64 kernel build:
$ cat neon.i
#pragma GCC push_options
#pragma GCC target "arch=armv8.2-a+bf16"
#pragma GCC pop_options
$ ./xgcc -B. ~/Programming/testcases/neon.i -c -mbranch-protection=pac-ret
/home/marxin/Programming/t
On 6/18/20 1:02 PM, Martin Liška wrote:
On 6/18/20 5:47 PM, Luis Machado wrote:
That's another one I noticed alongside the first one I reported.
That's good that you managed to reproduce it.
Can you please send me your .config and I can reproduce that locally.
Thanks,
Martin
Here
On 6/18/20 3:34 PM, Martin Liška wrote:
On 6/18/20 7:18 PM, Luis Machado wrote:
On 6/18/20 1:02 PM, Martin Liška wrote:
On 6/18/20 5:47 PM, Luis Machado wrote:
That's another one I noticed alongside the first one I reported.
That's good that you managed to reproduce it.
Can you p
49 matches
Mail list logo
