This patch addresses PR rtl-optimization/106594, a significant performance
regression affecting aarch64 recently introduced (exposed) by one of my
recent RTL simplification improvements. Firstly many thanks to
Tamar Christina for confirming that the core of this patch provides ~5%
performance
This patch implements new target hook TARGET_CONSTANT_OK_FOR_CPROP_P in
order to exclude CONST_INTs that cannot fit into a MOVI machine instruction
from cprop.
gcc/ChangeLog:
* config/xtensa/xtensa.c (TARGET_CONSTANT_OK_FOR_CPROP_P):
New macro definition.
Hi,
Many RISC machines, as we know, have some restrictions on placing
register-width constants in the source of load-immediate machine instructions,
so the target must provide a solution for that in the machine description.
A naive way would be to solve it early, ie. to replace with read
Le 11/09/2022 à 18:04, Torbjorn SVENSSON a écrit :
Can you fix it for me and submit it or do you want me to send a v3?
For trivial things like this, there is no need for a v3 (nor was there
for a v2).
Do you miss a git write account and need someone to push for you?
Hi,
On 2022-09-11 16:34, Mikael Morin wrote:
Hello,
diff --git a/gcc/testsuite/gcc.misc-tests/gcov.exp
b/gcc/testsuite/gcc.misc-tests/gcov.exp
index 82376d90ac2..a55ce234f6e 100644
--- a/gcc/testsuite/gcc.misc-tests/gcov.exp
+++ b/gcc/testsuite/gcc.misc-tests/gcov.exp
@@ -24,9 +24,9 @@
Hello,
diff --git a/gcc/testsuite/gcc.misc-tests/gcov.exp
b/gcc/testsuite/gcc.misc-tests/gcov.exp
index 82376d90ac2..a55ce234f6e 100644
--- a/gcc/testsuite/gcc.misc-tests/gcov.exp
+++ b/gcc/testsuite/gcc.misc-tests/gcov.exp
@@ -24,9 +24,9 @@ global GCC_UNDER_TEST
(...)
} else {
-set
> ...it took me a moment to realize that the analyzer "sees" that this is
> "main", and thus buf_size is 0.
>
> Interestingly, if I rename it to not be "main" (and thus buf_size could
> be non-zero), we still don't complain:
> https://godbolt.org/z/PezfTo9Mz
> Presumably this is a known
Le 11/09/2022 à 11:57, FX a écrit :
As a first step, one could check the use rename lists; what's done for
iso_fortran_env can be used as an example.
Yes, but iso_fortran_env is handled entirely in front-end, not through external
files.
That's true, but the standard check doesn't really
Hi Mikael,
> As a first step, one could check the use rename lists; what's done for
> iso_fortran_env can be used as an example.
Yes, but iso_fortran_env is handled entirely in front-end, not through external
files.
This is what I plan to do when migrating the IEEE modules to front-end, but it
Le 10/09/2022 à 12:14, FX via Fortran a écrit :
If you have a solution for the standards checking, I’ll add it.
As a first step, one could check the use rename lists; what's done for
iso_fortran_env can be used as an example.
To diagnose the other usages, the check could be put in
On Sun, 2022-09-11 at 10:21 +0200, Bernhard Reutner-Fischer wrote:
> On 11 September 2022 10:04:51 CEST, David Malcolm via Gcc-patches
> wrote:
>
> > > +++ b/gcc/testsuite/gcc.dg/analyzer/pr106845.c
> > > @@ -0,0 +1,11 @@
> > > +int buf_size;
> > > +
> > > +int
> > > +main (void)
> > > +{
> > >
On 11 September 2022 10:04:51 CEST, David Malcolm via Gcc-patches
wrote:
>> +++ b/gcc/testsuite/gcc.dg/analyzer/pr106845.c
>> @@ -0,0 +1,11 @@
>> +int buf_size;
>> +
>> +int
>> +main (void)
>> +{
>> + char buf[buf_size];
>> +
>> + __builtin_memset ([1], 0, buf_size);
>> +
>> + return 0;
>>
On Sun, 2022-09-11 at 00:19 +0200, Tim Lange wrote:
> Hi,
>
> see my patch below for a fix of pr106845. I decided to allow
> bit_ranges
> and byte_ranges to have a size of zero and rather only add an
> assertion
> to the functions that assume a non-zero size. That way is more
> elegant in
> the
13 matches
Mail list logo
