Hi Sebastian,
On 2/27/20 4:53 PM, Pop, Sebastian wrote:
Hi,
is somebody already working on backporting -moutline-atomics to gcc
8.x and 9.x branches?
I'm not aware of such work going on.
Thanks,
Kyrill
Thanks,
Sebastian
On 9/26/19 8:02 AM, Ramana Radhakrishnan wrote:
Hi,
I'm pleased to announce that the GCC steering committee has appointed
Kyrylo Tkachov and Richard Sandiford as AArch64 maintainers.
Please join me in congratulating them both on their additional roles
in the community. Kyrill / Richard, please
Hi Lijia,
On 6/12/19 4:22 AM, Li Jia He wrote:
Hi,
I recently did some analysis on the automatic vectorization of gcc, I
found that singed char can not be vectorized in the following code.
---
#define ITERATIONS 100
#if defined(do_reduce_signed_char)
#define TYPE signed char
#elif defined
Hi Kay,
On 09/01/19 08:29, Kay F. Jahnke wrote:
Hi there!
I am developing software which tries to deliberately exploit the
compiler's autovectorization facilities by feeding data in
autovectorization-friendly loops. I'm currently using both g++ and
clang++ to see how well this approach works. U
Hi Radu,
On 06/12/18 22:10, Radu Ometita wrote:
Hello everyone!
We are working on writing a paper about testing the reliability of C compilers
by using Csmith (a random C99 program generator).
A previous testing effort, using Csmith, found 79 GCC bugs, and 25 of those have been
marked by dev
Hi Richard,
On 09/05/18 19:37, Richard Biener wrote:
On May 9, 2018 6:19:47 PM GMT+02:00, Kyrill Tkachov
wrote:
Hi all,
I'm looking into implementing the usad/ssad optabs for aarch64 to catch
code like in PR 85693
and I'm a bit lost with what the midend expects the optabs to pr
Hi all,
I'm looking into implementing the usad/ssad optabs for aarch64 to catch code
like in PR 85693
and I'm a bit lost with what the midend expects the optabs to produce.
The documentation for them says that the addend operand (op 3) is of mode equal
or wider than
the mode of the product (and
Hi,
On 18/12/17 10:30, HEBBAL Yacine wrote:
Hello,
In one of my projects, I need to determine automatically what are the
names
and types of data fields manipulated by functions in binary code of a
given
program (e.g. Linux kernel).
I found that RTL dumps contains most of information I need in
On 09/09/17 12:44, Ramana Radhakrishnan wrote:
I'm pleased to announce that the steering committee has appointed
- James Greenhalgh as a full maintainer for the AArch64 port
and
- Kyrylo Tkachov as a full maintainer for the ARM port.
James & Kyrylo, if you could update your entries in the
On 11/05/17 11:43, Simon Wright wrote:
I see from https://gcc.gnu.org/install/test.html that it's possible to run
tests in parallel. I get the impression from gcc/Makefile that the check
concerned has to be set up in the Makefile (in my build tree, configured with
--target=x86_64-apple-darwin
On 10/03/17 23:56, Segher Boessenkool wrote:
On Fri, Mar 10, 2017 at 10:30:33AM +, Kyrill Tkachov wrote:
I'm trying to improve the cases where the result of the arithmetic
operation is used in multiple places besides the comparison.
For example:
add w0, w0, w1
On 10/03/17 10:23, Eric Botcazou wrote:
My understanding was that the order of the two in this pattern here doesn't
matter because there is an implicit PARALLEL around them, but I found that
the compare-elimination pass (compare-elim.c) assumes that the COMPARE set
must be in the second positio
Hi all,
Some (many?) targets have instructions that perform an arithmetic operation and
set the condition flags based on the result.
For example, on aarch64, we have instructions like ADDS, SUBS, ANDS etc.
In the machine description we represent them as a PARALLEL pattern of a COMPARE
and the a
On 06/01/17 14:22, Toon Moene wrote:
On the attached (Fortran) source, the following version of gfortran draws an
ICE:
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/confi
Hi all,
I'm working on a tree-ssa pass to implement PR 22141, a pass that merges
adjacent stores.
I've gotten to the point where I can identify the adjacent accesses, merge them
into a single value
and am now working on emitting the new statements but, as I don't have a lot of
experience with
Hi Jakub, Torvald,
On 03/06/16 13:32, Jakub Jelinek wrote:
On Fri, Jun 03, 2016 at 02:26:09PM +0200, Torvald Riegel wrote:
And that would be fine, IMO. If you can't even load atomically, doing
something useful with this type will be hard except in special cases.
Also, doing a CAS (compare-and-
Hi all,
expand_atomic_load in optabs.c tries to expand a wide atomic load using an
atomic_compare_and_swap
with the comment saying that sometimes a redundant harmless store may be
performed.
Is the store really valid if the memory is read-only?
I've been looking at implementing a similar compa
On 31/05/16 12:17, Richard Biener wrote:
On Tue, 31 May 2016, Kyrill Tkachov wrote:
Hi Richard,
On 27/05/16 12:43, Richard Biener wrote:
The first release candidate for GCC 5.4 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/5.4.0-RC-20160527
and shortly its mirrors. It has been
Hi Richard,
On 27/05/16 12:43, Richard Biener wrote:
The first release candidate for GCC 5.4 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/5.4.0-RC-20160527
and shortly its mirrors. It has been generated from SVN revision 236809.
I have sofar bootstrapped the release candidate on x
On 10/05/16 14:46, Richard Biener wrote:
On Tue, May 10, 2016 at 3:41 PM, Kyrill Tkachov
wrote:
Hi all,
I'm taking a stab at fixing PR 22141 by merging adjacent stores into wider
stores in a late gimple pass.
My current plan is to go through all the assignments in a basic block and
Hi all,
I'm taking a stab at fixing PR 22141 by merging adjacent stores into wider
stores in a late gimple pass.
My current plan is to go through all the assignments in a basic block and keep
track of
LHS expressions that are COMPONENT_REF, BIT_FIELD_REF, ARRAY_REF or
ARRAY_RANGE_REF until
we
Hi all,
I'm looking at an issue in RTL ifcvt and I'm trying to understand the way edges
between
basic blocks are treated and in particular what is the canonical use of
EDGE_FALLTHRU.
Is it governed by the conditional jump condition?
In find_if_header in ifcvt.c there is a comment that says:
On 08/03/16 19:11, Jeff Law wrote:
On 03/08/2016 11:49 AM, Richard Henderson wrote:
On 03/07/2016 02:49 PM, Jeff Law wrote:
On 03/07/2016 03:44 AM, Kyrill Tkachov wrote:
The RTL documentation for ASHIFT and friends says that the shift amount
must be:
"a fixed-point mode or be a con
On 05/03/16 05:52, Jeff Law wrote:
On 03/04/2016 09:33 AM, Kyrill Tkachov wrote:
On 04/03/16 16:21, Jeff Law wrote:
On 03/04/2016 08:05 AM, Richard Biener wrote:
does that mean that the shift amount should be DImode?
Seems like a more flexible approach would be for the midend to be able
to
On 04/03/16 16:21, Jeff Law wrote:
On 03/04/2016 08:05 AM, Richard Biener wrote:
does that mean that the shift amount should be DImode?
Seems like a more flexible approach would be for the midend to be able
to handle these things...
Or macroize for all integer modes?
That's probably worth ex
On 04/03/16 15:12, Kyrill Tkachov wrote:
On 04/03/16 15:07, Segher Boessenkool wrote:
On Fri, Mar 04, 2016 at 02:48:21PM +, Kyrill Tkachov wrote:
Although there are case where we hit the same problem:
unsigned long
f3 (unsigned long bit_addr)
{
unsigned long bitnumb = bit_addr &
On 04/03/16 15:07, Segher Boessenkool wrote:
On Fri, Mar 04, 2016 at 02:48:21PM +, Kyrill Tkachov wrote:
Although there are case where we hit the same problem:
unsigned long
f3 (unsigned long bit_addr)
{
unsigned long bitnumb = bit_addr & 63;
return (1L << bitnumb);
}
co
On 04/03/16 14:41, Kyrill Tkachov wrote:
On 04/03/16 11:59, Segher Boessenkool wrote:
On Mon, Feb 29, 2016 at 10:51:24AM +, Kyrill Tkachov wrote:
So I'm trying to create a define_insn to match something like:
[(set (match_operand:SI 0 "register_operand" "
On 04/03/16 11:59, Segher Boessenkool wrote:
On Mon, Feb 29, 2016 at 10:51:24AM +, Kyrill Tkachov wrote:
So I'm trying to create a define_insn to match something like:
[(set (match_operand:SI 0 "register_operand" "=r")
(ashift:SI
(match_operand:S
On 28/02/16 21:34, Joel Sherrill wrote:
On February 28, 2016 3:20:24 PM CST, Gerald Pfeifer wrote:
On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote:
I propose to commit this patch later this week.
+ Support for revisions of the ARM architecture prior to ARMv4t
has
+ been depr
Hi Jeff,
On 26/02/16 21:24, Jeff Law wrote:
On 02/26/2016 06:40 AM, Kyrill Tkachov wrote:
Hi all,
I'm looking at a case where some RTL passes create an RTL expression of
the form:
(subreg:QI (and:SI (reg:SI x1)
(const_int 31)) 0)
which I'd like to simplify to:
(and:QI
Hi all,
I'm looking at a case where some RTL passes create an RTL expression of the
form:
(subreg:QI (and:SI (reg:SI x1)
(const_int 31)) 0)
which I'd like to simplify to:
(and:QI (subreg:QI (reg:SI x1) 0)
(const_int 31))
Because (const_int 31) masks out the upper bits after
closed as such by someone who does
the analysis.
Kyrill
Thank you
~Umesh
On Fri, Feb 12, 2016 at 3:00 PM, Kyrill Tkachov
wrote:
Hi,
On 12/02/16 09:19, Umesh Kalappa wrote:
Hi Guys ,
we do have a issue with below code ,When we enabled the pie (-fpie/pie)
option
i.e
main.c
extern int *my_
Hi,
On 12/02/16 09:19, Umesh Kalappa wrote:
Hi Guys ,
we do have a issue with below code ,When we enabled the pie (-fpie/pie) option
i.e
main.c
extern int *my_ptr ;
int main()
{
return *my_ptr;
}
foo.s
.syntax unified
.cpu cortex-m0
.fpu softvfp
.thumb
.global my_ptr
Hi Jeff,
On 13/01/16 19:28, Jeff Law wrote:
On 01/13/2016 04:33 AM, Kyrill Tkachov wrote:
I've been able to get it to do the right thing by changing the line
where it initially folds the source of the SET. That is line 4639 in
cse.c: /* Simplify and foldable subexpressions in SRC. The
Hi all,
I'm looking at mitigating some of the codegen regressions on arm that come from
a proposed fix
to PR 65932 and I believe RTL CSE is getting in the way.
The problematic sequences involve sign-extending loads and sign-extending
multiplies.
From the gcc.target/arm/wmul-1.c case we have:
(
Hi Bin,
On 07/01/16 14:15, Bin.Cheng wrote:
Hi,
Below test is supposed to be compiled and run, but we failed to link
the binary with tiny memory model.
spawn
/data/work/build-aarch64_be-none-elf/obj/gcc2/gcc/testsuite/g++14/../../xg++
-B/data/work/build-aarch64_be-none-elf/obj/gcc2/gcc/testsui
On 14/08/15 16:31, Jeff Law wrote:
On 08/14/2015 03:05 AM, Kyrill Tkachov wrote:
The problem I'm trying to solve can be expressed in this way: "An
insn that satisfies predicate pred_p (insn) cannot appear exactly N
insns apart from another insn 'insn2' that satisfies pr
Hi Jeff,
On 13/08/15 17:20, Jeff Law wrote:
On 08/13/2015 05:06 AM, Kyrill Tkachov wrote:
Hi all,
I'm implementing a target-specific reorg pass, and one thing that I want
to do
is for a given insn in the stream to find an instruction
in the stream that I can swap it with, without viol
Hi all,
I'm implementing a target-specific reorg pass, and one thing that I want to do
is for a given insn in the stream to find an instruction
in the stream that I can swap it with, without violating any dataflow
dependencies.
The candidate instruction could be earlier or later in the stream.
On 17/07/15 11:43, Nikolai Bozhenov wrote:
Hello!
It is certainly true that debugging an optimized code is an inherently
difficult task. Though, I wonder if the compiler could make such
debugging experience slightly less surprising.
Consider the following example:
1 extern void bar(int
On 02/06/15 17:50, Jeff Law wrote:
On 06/02/2015 09:57 AM, Kyrill Tkachov wrote:
I'm stuck on noce_process_if_block (in ifcvt.c) and what I think is a
restriction that the THEN-block contents have to be only a single set
insn. This fails on aarch64 because we get an extra zero_extend
Hi all,
I'm looking at a case on aarch64 that's not if-converted to use conditional
moves:
typedef unsigned char uint8_t;
typedef unsigned int uint16_t;
uint8_t foo(const uint8_t byte, const uint16_t generator)
{
if (byte & 0x80) {
return (byte << 1) ^ (generator & 0xff);
} else {
On 19/05/15 16:21, Kyrill Tkachov wrote:
On 19/05/15 15:55, Christian Bruel wrote:
Hi Kiril,
This is funny, I've updated bz65837 today in the same direction.
On 05/19/2015 04:17 PM, Kyrill Tkachov wrote:
Hi all,
I'm working on enabling target attributes and pragmas on aarch64 and
On 19/05/15 15:55, Christian Bruel wrote:
Hi Kiril,
This is funny, I've updated bz65837 today in the same direction.
On 05/19/2015 04:17 PM, Kyrill Tkachov wrote:
Hi all,
I'm working on enabling target attributes and pragmas on aarch64 and I'm stuck
on a particular issue.
I
Hi all,
I'm working on enabling target attributes and pragmas on aarch64 and I'm stuck
on a particular issue.
I want to be able to use a target pragma to enable SIMD support in a SIMD
intrinsics header file.
So it will look like this:
$ cat simd_header.h
#pragma GCC push_options
#pragma GCC ta
On 18/05/15 09:25, Kyrill Tkachov wrote:
Hi Christian,
On 18/05/15 07:26, Christian Bruel wrote:
Hi Kyrill,
On 05/13/2015 05:43 PM, Kyrill Tkachov wrote:
Hi all,
Are target attributes supposed to redefine the preprocessor macros available?
For example, on aarch64 if the file is compiled
Hi Christian,
On 18/05/15 07:26, Christian Bruel wrote:
Hi Kyrill,
On 05/13/2015 05:43 PM, Kyrill Tkachov wrote:
Hi all,
Are target attributes supposed to redefine the preprocessor macros available?
For example, on aarch64 if the file is compiled with floating point support
the
Hi all,
Are target attributes supposed to redefine the preprocessor macros available?
For example, on aarch64 if the file is compiled with floating point support
the __ARM_FEATURE_FMA predefine is available. If the user adds to a function
a target attribute disabling floating point, then is __ARM
hristian
On 05/05/2015 03:38 PM, Kyrill Tkachov wrote:
Hi all,
I'm looking at implementing target attributes for aarch64 and I have some
questions about the hooks involved.
I haven't looked at this part of the compiler before, so forgive me if some of
them seem obvious. I couldn
Hi all,
I'm looking at implementing target attributes for aarch64 and I have some
questions about the hooks involved.
I haven't looked at this part of the compiler before, so forgive me if some of
them seem obvious. I couldn't
figure it out from the documentation
(https://gcc.gnu.org/onlinedoc
Hi all,
I'm trying to run a bootstrap on a 64-bit hppa-linux-gnu but am getting
an error when building libgcc:
/usr/include/features.h:374:25: fatal error: sys/cdefs.h: No such file or
directory
This suggests to me that it's a problem with multilibs.
I configured the build with --disable-multi
On 30/03/15 08:14, Bin.Cheng wrote:
On Sat, Mar 28, 2015 at 1:31 AM, Sandra Loosemore
wrote:
On 03/27/2015 03:43 AM, Kyrill Tkachov wrote:
On 27/03/15 03:29, Bin.Cheng wrote:
[much snippage]
As for tree ivopts, address cost is used in both ways. For any
address computation that&#
On 30/03/15 08:07, Bin.Cheng wrote:
On Fri, Mar 27, 2015 at 5:43 PM, Kyrill Tkachov wrote:
On 27/03/15 03:29, Bin.Cheng wrote:
On Thu, Mar 26, 2015 at 11:40 PM, Kyrill Tkachov
wrote:
Hi all,
I'd like to attempt to make GCC's usage of costs in the backends
consistent.
We hav
On 27/03/15 17:31, Sandra Loosemore wrote:
On 03/27/2015 03:43 AM, Kyrill Tkachov wrote:
On 27/03/15 03:29, Bin.Cheng wrote:
[much snippage]
As for tree ivopts, address cost is used in both ways. For any
address computation that's invalid, it tries to legitimize it into two
parts, the
On 27/03/15 03:29, Bin.Cheng wrote:
On Thu, Mar 26, 2015 at 11:40 PM, Kyrill Tkachov wrote:
Hi all,
I'd like to attempt to make GCC's usage of costs in the backends consistent.
We have a lot of different types: rtx costs, address costs, regmove costs,
vector costs etc. Some of th
Hi all,
I'd like to attempt to make GCC's usage of costs in the backends consistent.
We have a lot of different types: rtx costs, address costs, regmove costs,
vector costs etc. Some of them are use in different units, compared against
different types of costs and in general are a bit of a mess.
On 02/03/15 17:38, Ilya Tocar wrote:
On 02 Mar 15:22, Kyrill Tkachov wrote:
Hi all,
I'm looking at using the define_subst machinery to auto-generate
zero-extended
versions of some patterns, for example having:
(set reg:SI
(xor:SI a:SI b:SI))
generate a pattern of the form:
(set r
Hi all,
I'm looking at using the define_subst machinery to auto-generate
zero-extended
versions of some patterns, for example having:
(set reg:SI
(xor:SI a:SI b:SI))
generate a pattern of the form:
(set reg:DI
(zero_extend:DI
(xor:SI (a:SI b:SI
How do I go about achieving
On 01/12/14 08:20, Pengfei Yuan wrote:
Hi,
Hi,
In https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html , the
description of option `-freorder-blocks' says `in order to reduce
number of taken branches and improve code locality'. It is confusing.
When will the `and' condition happen? That
Hi all,
I'm seeing some relocation truncation failures in the libstdc++
testsuite where the test
is too large to fit into the memory model. In the gcc testsuite we mark
these tests as unsupported
using something like the below fragment in gcc-dg.exp
if { [regexp "(^|\n)\[^\n\]*: relocation tr
On 21/10/14 08:37, Ajit Kumar Agarwal wrote:
Hello All:
Memset and Memcpy calls are extensively used in many benchmarks. Inlining or
expansion
the memcpy and memset calls improves the performance of many performance
Benchmark.
I have implemented the expansion of strcmp to the optimizaed seque
Hi Shanyao,
On 03/09/14 16:02, shanyao chen wrote:
Hi,
I found there is a performance problem with some simd intrinsics
(vld2_dup_*) on aarch64-none-elf. Now the vld2_dup_* are defined as
follows:
#define __LD2R_FUNC(rettype, structtype, ptrtype, \
regsuffix, funcsuffix, Q) \
__extensio
On 18/08/14 10:19, Richard Earnshaw wrote:
On 14/08/14 09:45, Kyrill Tkachov wrote:
On 13/08/14 18:32, Segher Boessenkool wrote:
On Wed, Aug 13, 2014 at 03:57:31PM +0100, Richard Earnshaw wrote:
The problem with the frankenmonster patterns is that they tend to
proliferate into the machine
On 13/08/14 18:32, Segher Boessenkool wrote:
On Wed, Aug 13, 2014 at 03:57:31PM +0100, Richard Earnshaw wrote:
The problem with the frankenmonster patterns is that they tend to
proliferate into the machine description, and before you know where you
are the back-end is full of them.
Furthermore
On 12/08/14 16:16, Kyrill Tkachov wrote:
On 12/08/14 16:11, Kyrill Tkachov wrote:
On 12/08/14 15:22, Jeff Law wrote:
On 08/12/14 04:31, Kyrill Tkachov wrote:
On 12/08/14 10:39, Richard Biener wrote:
On Mon, Aug 11, 2014 at 9:56 PM, Jeff Law wrote:
On 08/11/14 07:41, Kyrill Tkachov wrote
On 12/08/14 16:11, Kyrill Tkachov wrote:
On 12/08/14 15:22, Jeff Law wrote:
On 08/12/14 04:31, Kyrill Tkachov wrote:
On 12/08/14 10:39, Richard Biener wrote:
On Mon, Aug 11, 2014 at 9:56 PM, Jeff Law wrote:
On 08/11/14 07:41, Kyrill Tkachov wrote:
I haven't been able to get combi
On 12/08/14 15:22, Jeff Law wrote:
On 08/12/14 04:31, Kyrill Tkachov wrote:
On 12/08/14 10:39, Richard Biener wrote:
On Mon, Aug 11, 2014 at 9:56 PM, Jeff Law wrote:
On 08/11/14 07:41, Kyrill Tkachov wrote:
I haven't been able to get combine to match the comparison+xor+neg+plus
RTL a
On 12/08/14 10:39, Richard Biener wrote:
On Mon, Aug 11, 2014 at 9:56 PM, Jeff Law wrote:
On 08/11/14 07:41, Kyrill Tkachov wrote:
I haven't been able to get combine to match the comparison+xor+neg+plus
RTL and it seems like it would be just a workaround to undo the
tree-
Hi all,
The aarch64 target has a conditional negation instruction
CSNEG Rd, Rs1, Rs2, cond
with semantics Rd = if cond then Rs1 else -Rs2.
This, however doesn't get end up getting matched for code such as:
int
foo2 (unsigned a, unsigned b)
{
int r = 0;
r = a & b;
if (a & b)
return -r;
On 23/07/14 09:59, Kyrill Tkachov wrote:
On 23/07/14 09:55, Richard Earnshaw wrote:
On 22/07/14 16:23, Ramana Radhakrishnan wrote:
On 22/07/14 14:14, Kyrill Tkachov wrote:
Hi all,
In the arm backend we've got this TARGET_UNIFIED_ASM macro that is
currently on for TARGET_THUMB2 w
On 23/07/14 09:55, Richard Earnshaw wrote:
On 22/07/14 16:23, Ramana Radhakrishnan wrote:
On 22/07/14 14:14, Kyrill Tkachov wrote:
Hi all,
In the arm backend we've got this TARGET_UNIFIED_ASM macro that is
currently on for TARGET_THUMB2 with a comment that says:
/* We could use un
Hi all,
In the arm backend we've got this TARGET_UNIFIED_ASM macro that is
currently on for TARGET_THUMB2 with a comment that says:
/* We could use unified syntax for arm mode, but for now we just use it
for Thumb-2. */
I've been doing some work converting the pre-UAL floating point
mnemo
Hi David,
On 22/07/14 02:46, David Wohlferd wrote:
I have been looking at asm_fprintf in final.c, and I think there's a
design flaw. But since the change affects ARM and since I have no
access to an ARM system, I need a second opinion.
asm_fprintf allows platforms to add support for new format
Hi all,
Consider code:
long int
foo (double a)
{
return __builtin_round (a);
}
Compiling for aarch64-none-elf (bare-metal aarch64 with newlib as
C-library) with -O2 gives the 003t.original dump:
;; Function foo (null)
;; enabled by -tree-original
{
return (long int) __builtin_round (a)
On 28/05/14 17:36, Alexander Monakov wrote:
On Wed, 28 May 2014, Kyrill Tkachov wrote:
Hi all,
The documentation for TARGET_MACRO_FUSION_PAIR says that it can be used to
tell the scheduler that two insns should not be scheduled apart. It doesn't
specify what kinds of insns those c
Hi all,
The documentation for TARGET_MACRO_FUSION_PAIR says that it can be used
to tell the scheduler that two insns should not be scheduled apart. It
doesn't specify what kinds of insns those can be.
Yet from what I can see in sched-deps.c it can only be used on compares
and conditional bra
On 15/05/14 09:52, Ramana Radhakrishnan wrote:
On Thu, May 15, 2014 at 8:36 AM, Maxim Kuvyrkov
wrote:
On May 15, 2014, at 6:46 PM, Ramana Radhakrishnan
wrote:
I'm not claiming it's a great heuristic or anything. There's bound to
be room for improvement. But it was based on "reality" and re
Hi all,
In haifa-sched.c (in rank_for_schedule) I notice that live range shrinkage is
not performed when SCHED_PRESSURE_MODEL is used and the comment mentions that it
results in much worse code.
Could anyone elaborate on this? Was it just empirically noticed on x86_64?
Thanks,
Kyrill
On 28/04/14 18:03, Kenneth Zadeck wrote:
At this point we have believe that we have addressed all of the concerns
that the community has made about the wide-int branch. We have also
had each of the sections of the branch approved by the area maintainers.
We are awaiting a clean build on the ar
On 24/04/14 22:07, Jan-Benedict Glaw wrote:
Hi!
Seems the new cost model for Cortex A8 is missing two initializer
fields:
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing
On 10/04/14 02:50, Maxim Kuvyrkov wrote:
On Apr 9, 2014, at 4:15 AM, Kyrill Tkachov wrote:
Hi all,
I'm looking at some curious pre-reload scheduling behaviour and I noticed this:
At the add_branch_dependences function sched-rgn.c there is a comment that says
"branches, c
Hi all,
I'm looking at some curious pre-reload scheduling behaviour and I noticed this:
At the add_branch_dependences function sched-rgn.c there is a comment that says
"branches, calls, uses, clobbers, cc0 setters, and instructions that can throw
exceptions" should be scheduled at the end of t
On 27/02/14 11:07, Andrew Haley wrote:
Over the years there has been a great deal of traffic on these lists
caused by misunderstandings of GCC's inline assembler. That's partly
because it's inherently tricky, but the existing documentation needs
to be improved.
dw has done a fairly thorough re
Hi Richard,
I noticed that Makefile.in in libatomic sets -march=armv7-a when compiling for
arm linux targets with ifunc support:
@ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -march=armv7-a
-DHAVE_KERNEL64
Is there any particular reason why it must do that?
It seems that if we're try
Hi all,
I'm investigating a testsuite failure on arm: gcc.target/arm/unsigned-extend-1.c
For code:
unsigned char foo (unsigned char c)
{
return (c >= '0') && (c <= '9');
}
we end up generating:
sub r0, r0, #48
uxtbr0, r0
cmp r0, #9
movhi r0, #0
On 16/10/13 10:37, pins...@gmail.com wrote:
On Oct 15, 2013, at 6:58 AM, Igor Zamyatin wrote:
Hi All!
Is there any particular reason that matmul* modules from libgfortran
are compiled with -O2 -ftree-vectorize?
I see some regressions on Atom processor after r202980
(http://gcc.gnu.org/ml/gcc-c
87 matches
Mail list logo
