We'll be the first port to use BImode and have STORE_FLAG_VALUE==-1.
That has exposed some bugs, one of them is in combine where we can end
up calling num_sign_bit_copies for a BImode value. However, the return
value is always 1 in that case, so it doesn't tell us anything and is
going to be
ptx doesn't have indirect jumps, so CODE_FOR_indirect_jump may not be
defined. Add a sorry.
gcc/
* optabs.c (emit_indirect_jump): Test HAVE_indirect_jump and emit a
sorry if necessary.
Index: gcc/optabs.c
This is actually an old patch from the C6X 40-bit-int patchkit which
fell through the cracks. It turns out to be necessary for ptx to get
correct behaviour for BImode.
gcc/
* stor-layout.c (get_mode_bounds): Use GET_MODE_PRECISION, not
GET_MODE_BITSIZE. Handle BImode specially.
It turns out that we're calling eliminate_regs for global variables which
can't possibly have eliminable regs in their decl. At that point,
reg_eliminate can be NULL. This patch avoids unnecessary work, and
allows us to add an assert to eliminate_regs later.
gcc/
* dbxout.c (dbxout_symbol):
Use fix_string_type to get all string types.
When making a decl for __FUNCTION__ we use a slightly different method
than elsewhere to arrive at a string type. This changes it to use the
common idiom. On ptx these types will have an address space, and this
ensures that we don't drop it when
This fixes an oversight where a C_MAYBE_CONSTANT_EXPR could survive
until gimplification and trigger an assert.
gcc/c-family/
* c-common.c (c_fully_fold_internal): Handle ADDR_SPACE_CONVERT_EXPR.
Index:
This goes together with patch #13.
This adds a target hook to avoid doing register allocation or reload and
changes some code not to crash in such a case.
gcc/
* target.def (no_register_allocation): New data hook.
* doc/tm.texi.in: Add @hook TARGET_NO_REGISTER_ALLOCATION.
* doc/tm.texi:
Most of the compiler expects TYPE_ADDR_SPACE to be valid for things like
initializing a MEM. The C frontend does not set it for arrays, which
seems like an oversight caused by not setting other type qualifiers for
array types.
gcc/
* tree.h (set_type_quals): Declare.
* tree.c
There's code in function.c to set the return register to the address of
a returned structure even though the return really happens through the
struct pointer passed as an invisible argument. This is unwanted on ptx,
where having a return value does not match the declaration of the
function or the
The last user of this was in objc and has been removed a while ago.
gcc/c-family/
* c-common.h (enum c_tree_index): Remove CTI_INT_ARRAY_TYPE.
(int_array_type_node): Remove.
* c-common.c (c_common_nodes_and_builtins): Don't build it.
There are two ways symbols can be output in ptx, either as plain x,
which represents the address in the .global address space, or as
generic(x) which is the converted form to a generic address. To
distinguish the cases, it's necessary to allow ADDR_SPACE_CONVERT_EXPRs
in initializers, and to deal
To be used together with the no_register_allocation hook.
Everything after register allocation is currently in pass_postreload
rather than pass_rest_of_compilation. This seems arbitrary to me, and
for a target that doesn't do register allocation, pass_postreload isn't
run, so the very last few
ptx assembly follows rather different rules than what's typical elsewhere.
We need a new hook to add a }; string when we are finished outputting a
variable.
gcc/
* target.def (decl_end): New hook.
* varasm.c (assemble_variable_contents, assemble_constant_contents):
Use it.
* doc/tm.texi.in
Consider
int x; /* Global address space is implicit for nvptx. */
int *p = x;
where x is a variable in __global address space, and p is a generic
pointer. We won't get very far if this doesn't work, so we must change
the C frontend to allow this conversion. This works together with the
Another small patchlet to prepare for implicit address spaces. We'll
modify char_array_type_node etc. to have an address space for nvptx, and
we'll need to be careful to retain it in fix_string_type.
gcc/c-family/
* c-common.c (fix_string_type): Get the element type from the value's
type if
The nvptx backend is slightly unusual in that call insns set a pseudo.
The combiner is surprised by this and allows combining them into other
insns, which remain as INSN rather than CALL_INSN. Aborts ensue.
gcc/
* combine.c (try_combine): Don't allow a call as one of the source
insns.
This adds two hooks to determine address spaces for local and global
variables, and changes various places in the compiler to ensure stuff
goes to the right place.
If a type is given an address space in this way, the
TYPE_QUAL_AS_IMPLICIT is set. Such a flag is needed to properly handle
such
On ptx, we'll be using pseudos to pass function args as well, and
there's one assert that needs to be toned town to make that work.
gcc/
* expr.c (use_reg_mode): Just return for pseudo registers.
Index: gcc/expr.c
On ptx we need to decorate call insns with the arguments that are
being passed. This is kind of hard to do with the existing
infrastructure, so this patch adds two more hooks, one called just
before argument registers are loaded (once for each arg), and the
other just after the call is complete.
ptx assembly has some unusual requirements, Symbols must be declared
before use, and only functions (but not variables) can have forward
declarations.
This patch deals with getting variable definitions in the right order,
emitting declarations for undefined symbols, and emitting declarations
for
On 12/09/2013 11:42 PM, Joseph S. Myers wrote:
On Mon, 9 Dec 2013, Bernd Schmidt wrote:
Most of the compiler expects TYPE_ADDR_SPACE to be valid for things like
initializing a MEM. The C frontend does not set it for arrays, which
seems like an oversight caused by not setting other type
On 11/29/2013 06:12 PM, Jakub Jelinek wrote:
On Fri, Nov 29, 2013 at 06:07:38PM +0100, Bernd Schmidt wrote:
By what mechanism do you choose? This is unclear to me from what I've
seen. Does this involve user action, and what's the advantage of doing
it this way?
See the 3 threads I've
On 11/20/2013 10:36 AM, Jakub Jelinek wrote:
On Wed, Nov 20, 2013 at 10:34:30AM +0100, Richard Biener wrote:
On Tue, Nov 19, 2013 at 10:58 AM, Ilya Tocar tocarip.in...@gmail.com wrote:
On 14 Nov 11:27, Richard Biener wrote:
+ /* Set when symbol needs to be dumped for lto/offloading. */
+
This one is small and pretty self-explanatory.
Bernd
2013-09-05 Nathan Sidwell nat...@codesourcery.com
* configure.ac: Add --enable-accelerator.
* configure: Rebuilt.
Index: gomp-4_0-branch/configure.ac
===
---
This adds Makefile and configure goop to enable building an accelerator
gcc in its own subdirectory along with the host compiler.
Bernd
* Makefile.def (host_modules, dependencies): Add accel-gcc entries.
(flags_to_pass): Add accel_target_alias).
* Makefile.tpl (accel_target_alias,
This is the largest patch (can be split up more, but I wanted to get
this out the door).
It adds the list of output targets which I hope someone will find a
better name for, the corresponding DECL_TARGET, and mechanisms to write
out lto for multiple targets. Also moves LTO section names into a
This doesn't get very far yet, but it's the start of what I imagine the
lto-wrapper changes will look like.
Bernd
Index: gomp-4_0-branch/gcc/lto-wrapper.c
===
--- gomp-4_0-branch.orig/gcc/lto-wrapper.c
+++
On 11/29/2013 01:36 PM, Richard Biener wrote:
Note that we (SUSE/AMD) sofar think we can go an easier route, not
adding a real backend that targets HSAIL/BRIG but instead use a
custom GIMPLE SSA - HSAIL/BRIG translator (including a SSA
based register allocator). Which if course simplifies
On 11/29/2013 02:05 PM, Kirill Yukhin wrote:
On 29 Nov 13:17, Bernd Schmidt wrote:
5. There's a new DECL_TARGET which refers to this list of target
machines. It's set when creating a child function from e.g. #pragma acc
parallel
Actually, I do not understand, what term `target machine' means
On 11/29/2013 04:16 PM, Jakub Jelinek wrote:
As you want to dump the GIMPLE IL right out of ~ IPA stage, it should in
theory be target independent, so it is undesirable to emit it several times
for each offloading target.
That's not what happens. It's just partitioned into disjoint sets, one
On 11/29/2013 06:03 PM, Jakub Jelinek wrote:
On Fri, Nov 29, 2013 at 05:57:25PM +0100, Bernd Schmidt wrote:
On 11/29/2013 04:16 PM, Jakub Jelinek wrote:
As you want to dump the GIMPLE IL right out of ~ IPA stage, it should in
theory be target independent, so it is undesirable to emit
On 11/23/2013 08:20 PM, Mike Stump wrote:
Richi has asked the we break the wide-int patch so that the individual port
and front end maintainers can review their parts without have to go through
the entire patch.This patch covers the bfin port.
Ok?
I haven't seen any updates on the
On 11/22/2013 09:15 AM, Richard Sandiford wrote:
I have a patch to upgrade most genrecog warnings into errors. This patch
fixes one for bfin about {push,pop}_multiple_operation not being defined
at the .md level.
Tested by building bfin-elf with the warnings turned to errors, and by
On 11/22/2013 12:50 PM, Richard Sandiford wrote:
Bernd Schmidt ber...@codesourcery.com writes:
On 11/22/2013 09:15 AM, Richard Sandiford wrote:
+extern int push_multiple_operation_p (rtx);
+extern int pop_multiple_operation_p (rtx);
I was once told that functions with side effects shouldn't
On 11/16/2013 11:01 AM, Chung-Lin Tang wrote:
My response to the various issues you raised are below. The new patch
has been re-tested. Please see if you can approve for committing now.
I agree with all the comments Richard has been making, so I'll just add
a few other points.
If you don't
I'm looking into using LTO to pass information between compilers for
different targets, for the OpenACC implementation. This area of the
compiler seems somewhat obfuscated by overengineering, and I'd like to
simplify it first to make it easier to work with.
lto_gimple_out and lto_finish_out
On 11/04/2013 04:31 AM, bin.cheng wrote:
2013-11-01 Bin Cheng bin.ch...@arm.com
* tree-ssa-loop-ivopts.c (enum ainc_type): New.
(address_cost_data): New field.
(get_address_cost): Compute auto-increment rtx cost in ainc_costs.
Use ainc_costs for auto-increment rtx
On 11/18/2013 02:03 PM, Jan Hubicka wrote:
On Mon, Nov 18, 2013 at 11:10 AM, Bernd Schmidt ber...@codesourcery.com
wrote:
The following patch simplifies this by getting rid of
all_lto_gen_passes. We could simplify a little further if we decided we
really don't need two different timevars
This fixes some minor ugliness I noticed while looking at this code. It
renames a poorly named global variable (shadowed by some function args
in the same file), replaces a cast of an integer value to a pointer, and
removes an undocumented and unused return value.
Bootstrapped and tested on
On 11/06/2013 10:31 AM, Richard Biener wrote:
We decided to move to C++. As part of a later discussion we decided
to go with a single general dynamic-casting style, mimicing the real
C++ variant which is dynamic_cast ... . Which resulted in
is-a.h.
So yes, we've decided to go C++ so we
On 11/06/2013 12:31 PM, Richard Biener wrote:
That I agree to. Instead of fixing the less than optimal separation /
boundary
between frontends and the middle-end, or fixing several other long-standing
issues with GCC we spend a lot of time refactoring things to be C++.
But that was kind of
On 10/18/2013 01:18 PM, Richard Biener wrote:
Index: gcc/fold-const.c
===
--- gcc/fold-const.c (revision 203267)
+++ gcc/fold-const.c (working copy)
@@ -7270,8 +7270,8 @@ fold_plusminus_mult_expr (location_t loc, enum tre
On 10/18/2013 02:10 PM, Richard Biener wrote:
On Fri, Oct 18, 2013 at 2:02 PM, Bernd Schmidt ber...@codesourcery.com
wrote:
On 10/18/2013 01:18 PM, Richard Biener wrote:
Index: gcc/fold-const.c
===
--- gcc/fold-const.c
On 07/14/2013 09:54 AM, Chung-Lin Tang wrote:
Hi, the last ping of the Nios II patches was:
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01416.html
After assessing the state, we feel it would be better to post a
re-submission of the newest patches.
Since this hasn't attracted attention for
On 07/14/2013 09:54 AM, Chung-Lin Tang wrote:
These are nios2 patches for the gcc testsuite. Some new testcases were
added since the last posting.
Index: gcc/testsuite/gcc.c-torture/execute/builtins/lib/chk.c
===
---
The sequence of events here can be summarized as shrink-wrapping causes
the i386 backend to do something that confuses alias analysis. The
miscompilation is that two instructions are swapped by the scheduler
when they shouldn't be, due to an incorrect reg_base_value.
The miscompiled function has
.
I'm thinking this probably ought to go into 4.8 as well.
Bernd
commit 6a77b1fca11e2fe9ac20aba2a241ead5a8ebd701
Author: Bernd Schmidt ber...@codesourcery.com
Date: Tue Oct 15 12:16:07 2013 +0200
Fix a miscompilation where a reload reg is reused after it has been clobbered
On 09/04/2013 06:04 PM, Jan Hubicka wrote:
this is third fallout of my change to remove DECL_ARGUMENTS/DECL_RESULT for
functions w/o
bodies I did not really anticipate.
[...]
I would like to basically ask if it seems to make sense to go this route and
try to get rid of those declarations.
On 09/04/2013 07:09 PM, Jan Hubicka wrote:
How do you support KR functions here? My basic idea was that TYPE_ARG_TYPES
should give enough information about external function calling convention
anyone will ever need. I would hope that this will be sufficient for your
use, too, despite the fact
On 08/19/2013 11:05 PM, Jeff Law wrote:
On 07/20/2013 03:02 AM, Alexey Makhalov wrote:
Hello!
If delete_unmarked_insns deletes some insn, DF state might be
out of date, and, regs_ever_live might contain unused registers till
the end.
(I can't find the original mail either in my mailbox or
On 07/20/2013 01:32 AM, DJ Delorie wrote:
Every pattern that is using (subreg:SI (thing:PSI)) needs to be
explained on this list and given an explicit clearance. It really looks
like you're just papering over problems elsewhere.
Most of them are just optimizations, but the problem with
On 06/21/2013 01:00 PM, Andreas Krebbel wrote:
On 20/06/13 02:00, Vladimir Makarov wrote:
I hope the following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604
Although I have no specific hardware to check this.
The patch also adds a comment about one recent change as it was
This is bug that triggers on m68k. The loop unroller creates a MULT
expression and tries to force it into a register, which causes a libcall
to be generated. Since args are pushed we create a
(use (mem (plus virtual_outgoing_args scratch)))
in CALL_INSN_FUNCTION_USAGE. Since we're past vregs,
On 06/17/2013 02:27 PM, Julian Brown wrote:
On Mon, 17 Jun 2013 13:38:05 +0200
Richard Biener richard.guent...@gmail.com wrote:
On Mon, Jun 17, 2013 at 1:31 PM, Julian Brown
jul...@codesourcery.com wrote:
IIUC, the incompatibility between the specified
-fstrict-volatile-bitfields behaviour
On 06/07/2013 10:43 PM, Richard Henderson wrote:
But these I think require a good hard look to see if they really intended an
ABI alignment:
c6x comment explicitly mentions abi
The ABI specifies a minimum alignment for arrays.
Bernd
On 06/10/2013 12:55 PM, Jakub Jelinek wrote:
On Mon, Jun 10, 2013 at 12:51:05PM +0200, Bernd Schmidt wrote:
On 06/07/2013 10:43 PM, Richard Henderson wrote:
But these I think require a good hard look to see if they really intended an
ABI alignment:
c6x comment explicitly mentions abi
On 05/27/2013 01:13 PM, Eric Botcazou wrote:
I have just created a new branch off the trunk named scalar-storage-order to
host the (experimental) support to specify a reverse storage order (byte/word
order, aka endianness) for scalar components of aggregate types.
I will be maintaining the
, the following patch is a
cut-down version of CodeSourcery's approach, originally written by
Nathan Froyd, modified to do exactly that.
Bootstrapped and tested on x86_64-linux, all languages except Ada. OK?
Bernd
commit ce5d3fe1bf7934dd551b7bf091f113f396e15d64
Author: Bernd Schmidt ber...@codesourcery.com
On 06/06/2013 04:52 PM, Richard Biener wrote:
+ /* We cannot optimize away a static used in multiple functions (as
+might happen in C++). */
+ !DECL_NONLOCAL(var)
it may also happen trivially with inlining. Which means a local pass can
never
remove vars safely.
This
On 04/26/2013 05:17 PM, Michael Zolotukhin wrote:
gcc/ChangeLog
2013-04-26 Michael Zolotukhin michael.v.zolotuk...@intel.com
* read-rtl.c (copy_rtx_for_iterators): Continue applying iterators
while it has any effect.
Ok.
Bernd
On 04/27/2013 10:39 AM, Richard Sandiford wrote:
Argh, that's unfortunate. The point of that change was to make
simplify_gen_unary (TRUNCATE, ...) no worse than using a subreg.
Would the equivalent lowpart simplify_gen_subreg call succeed
(return nonnull)? If so, I think we want truncate to
Currently, MEM_REF contains two pointer arguments, one which is supposed
to be a base object and another which is supposed to be a constant
offset. This representation is somewhat problematic, as not all machines
treat pointer values as essentially integers. On machines where size_t
is smaller
On 04/28/2013 11:13 PM, DJ Delorie wrote:
I have patches to let one specify a precision for partial int types,
easy enough to do, and the rest of the compiler plays nicely for the
most part with it...
If you can make size_t truly be a 24-bit value, I'd be very happy :-)
This confuses me a
On 04/24/2013 09:14 PM, DJ Delorie wrote:
24 bits stored as three bytes, or four? How does this affect vtable
layout? I would have expected the C++ frontend and libsupc++ to
currently be inconsistent with each other given such a setup.
In memory, four, I think. The address registers really
This patch here:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00661.html
changed simplification code from
case TRUNCATE:
- /* We can't handle truncation to a partial integer mode here
- because we don't know the real bitsize of the partial
- integer mode. */
- if
On 04/24/2013 05:10 PM, DJ Delorie wrote:
this isn't true, it would be helpful to know. Given the size_t/uintptr_t
testsuite patch I just submitted I'm thinking they don't exist, but I'm
kind of wondering about m32c, so Cc'ing DJ.
For m32c-elf with -mcpu=m32c, size_t is 16 bits but void*
Before the target was removed, IRIX defined DWARF_FRAME_RETURN_COLUMN to
be reg 64, which is something other than INCOMING_RETURN_ADDR_RTX (reg
31). This means that when we see a save of reg 31, we discover that
this is really a save of reg 64 and produce dwarf information
accordingly. However,
This fixes C++ testcases that used size_t when casting a pointer to
integer so that they use intptr_t instead. There's also an testcase
using pointer subtraction where ptrdiff_t is the correct choice, and a
fix to the ptrmem.C testcase to use sizeof on a function pointer rather
than a data
The pr8781.C testcase appears to have undefined behaviour as far as I
can tell. A function called noop is called with argument pred; this
creates a noop_t object which stores a reference to that argument, and
then the function returns the object. At that point I think the
reference becomes stale.
the previous code.
Bootstrapped and tested on x86_64-linux, ok?
Bernd
commit 618d06f7d414842a934fb360fa98972478e13483
Author: Bernd Schmidt ber...@codesourcery.com
Date: Tue Apr 23 15:19:07 2013 +0200
Allow empty arrays to be initialized
This undoes an earlier change
Author: Bernd Schmidt ber...@codesourcery.com
Date: Tue Apr 23 15:17:34 2013 +0200
Allow virtual table refs to be COMPONENT_REFs
This is a preparation patch for changing the C++ vtable layout. It makes
gimple-fold aware of how to fold a vtable reference that is a COMPONENT_REF
that at
least it doesn't crash on some vtable testcases, but realistically I
have no way of properly testing that target. Ok?
Bernd
commit d6957d8e1ad8179c01d373f741099b021a05730f
Author: Bernd Schmidt ber...@codesourcery.com
Date: Mon Apr 15 11:24:04 2013 +0200
Change handling of vtables to use fields
On 04/17/2013 11:52 PM, Steven Bosscher wrote:
According to the comments in pa.h about MASK_JUMP_IN_DELAY, having
jumps in delay slots of other jumps is one such thing: They don't
bring benefit to the PA-8000 and they don't work with DWARF2 CFI. As
far as I know, SPARC and MIPS don't allow
On 03/19/2013 04:37 PM, Richard Biener wrote:
On Tue, 19 Mar 2013, Richard Biener wrote:
Which shows that I need to merge the IRA and reload/lra passes.
Honza tells me that they are considered separate has historical
reasons only. Given that reload pushes TV_IRA and that the boundary
isn't
On 04/11/2013 12:05 PM, Richard Biener wrote:
Any particular suggestions? The easiest split is to emit
a ' reload/lra =' marker (or similar).
It's about getting a dump of the insns, in two separate files so that
one can do diffs (between sched1/ira or ira/reload).
On 04/11/2013 12:26 PM, Richard Biener wrote:
The point was not to remove TODO_ggc_collect, the point was to
both enforce the GC boundary at all passes (that's what the pass
manager assumes anyway) and to collect when necessary at such
well-defined boundaries. Another approach would have
On 12/06/2012 01:31 PM, Steven Bosscher wrote:
Hello,
The problem in this PR is that new basic blocks can be created if the
scheduler moves speculative insns and adds recovery code, but the
bb_state* arrays are allocated only at the start of scheduling a
region and are not set up to deal
Count another vote for getting rid of GC.
Bernd
On 11/07/2012 11:41 AM, Paulo Matos wrote:
Yes, the reordering works fine. The problem is when I change the
value of *n_readyp. The c6x port returns n_ready (which for me
doesn't make sense since the max insns I can schedule in a cycle is 2
which is my issue_rate), but doesn't change
On 11/07/2012 12:08 PM, Paulo Matos wrote:
-Original Message-
From: Bernd Schmidt [mailto:ber...@codesourcery.com]
Sent: 07 November 2012 10:48
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: Defining scheduling resource constraint
Yes... I seem to remember the documentation
On 11/06/2012 05:50 PM, Paulo Matos wrote:
I am following your advice and using sched.reorg to remove the
instruction from the ready list. What I am doing is checking the
register written in ready[n_ready - 1] (if any) and look for the
remainder of the ready list for insns writing to the same
If we have
i1: [r1 + 24] = x
i2: r1 = r1 + 24;
i3: y = [r1]
then, if not using cselib, we do not generate a dependency between i3
and i1, since we compare memory addresses [r1] and [r1 + 24]. This is
somewhat lame, but safe since i2 depends on i1 and i3 depends on i2.
However, it breaks with the
On 11/05/2012 03:51 PM, Paulo Matos wrote:
Hello,
I am experience a problem in GCC4.7 scheduler whereby the scheduler is
issuing two instructions that write with a cond_exec to the same register. It
ends up looking like this:
Cond_exec p1 != 0 : r2 - r2 and 0xf8
Cond_exec p0 != 0: r2 -
On 11/05/2012 06:11 PM, Paulo Matos wrote:
-Original Message-
From: Bernd Schmidt [mailto:ber...@codesourcery.com]
Sent: 05 November 2012 16:52
To: Paulo Matos
Cc: gcc@gcc.gnu.org
Subject: Re: Defining scheduling resource constraint
Depends on why it schedules them in the same
On 10/31/2012 01:12 PM, Richard Sandiford wrote:
OK with those changes for the rtl bits. Can't approve the generator
stuff though.
That's also OK.
Bernd
On 10/16/2012 04:30 AM, Vladimir Makarov wrote:
In insn:
(define_insn_and_split *lea_general_1
[(set (match_operand 0 register_operand =r)
(plus (plus (match_operand 1 index_register_operand l)
(match_operand 2 register_operand r))
(match_operand 3
On 10/15/2012 06:41 AM, Joern Rennecke wrote:
The following patch is still awaiting review:
2011-09-19 Jorn Rennecke joern.renne...@arc.com
* genoutput.c (process_template): Process '*' in '@' alternatives.
* doc/md.texi (node Output Statement): Provide example for the
On 08/13/2012 05:42 PM, Vladimir Makarov wrote:
On 08/13/2012 06:32 AM, Bernd Schmidt wrote:
This is a small patch for sched-rgn that attempts to save DFA state at
the end of a basic block and re-use it in successor blocks. This was a
customer-requested optimization; I've not seen it make much
On 09/28/2012 12:59 AM, Vladimir Makarov wrote:
+ We keep RTL code at most time in such state that the virtual
+ registers can be changed by just the corresponding hard registers
+ (with zero offsets) and we have the right RTL code. To achieve this
+ we should add initial offset
On 10/01/2012 12:14 PM, Jakub Jelinek wrote:
On Mon, Oct 01, 2012 at 12:01:36PM +0200, Steven Bosscher wrote:
I would also agree if it were not for the fact that IRA is already a
scalability bottle-neck and that has been known for a long time, too.
I have no confidence at all that if LRA goes
===
--- gcc/ChangeLog (revision 191837)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2012-09-20 Bernd Schmidt ber...@codesourcery.com
+
+ PR bootstrap/54688
+ * sched-deps.c (parse_add_or_inc): Remove MINUS handling. Take
+ STACK_GROWS_DOWNWARD
On 09/20/2012 07:42 PM, H.J. Lu wrote:
On Fri, Aug 3, 2012 at 5:05 AM, Bernd Schmidt ber...@codesourcery.com wrote:
This patch allows us to change
rn++
rm=[rn]
into
rm=[rn + 4]
rn++
This caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54645
The jury is still out
On 09/17/2012 07:32 PM, Ulrich Weigand wrote:
In any case, the change in the condition you noticed was introduced by a
recent
patch by Bernd: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00171.html
It seems that we ought to use a similar test to what Bernd introduced in
gen_reload, that
On 08/03/2012 02:05 PM, Bernd Schmidt wrote:
This patch allows us to change
rn++
rm=[rn]
into
rm=[rn + 4]
rn++
Ping.
Bernd
This is a small patch for sched-rgn that attempts to save DFA state at
the end of a basic block and re-use it in successor blocks. This was a
customer-requested optimization; I've not seen it make much of a
difference in any macro benchmarks.
Bootstrapped and tested on x86_64-linux and also
===
--- gcc/ChangeLog (revision 190317)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2012-08-11 Bernd Schmidt ber...@codesourcery.com
+
+ * reload1.c (replaced_subreg, gen_reload): Add
+ SECONDARY_MEMORY_NEEDED ifdefs as necessary.
+
2012-08-11 Jan
There are a number of problems in the interaction between secondary
memory and subregs. If we reload the inner of a subreg, we forget about
this when deciding whether to use secondary memory, and just use
REGNO_REG_CLASS on the (now reloaded) inner.
Also, we don't really know what to do if we get
On 08/03/2012 08:50 PM, Uros Bizjak wrote:
Hello!
Bootstrapped and tested on i686-linux. It's also been in several of our
internal trees, going back to even 4.4-based ones IIRC, and has had
testing for several architectures. Ok for the i386 part? I intend to
check the reload bits in soon if
We're moving a load across a call since we don't recognize calls as
memory-clobbering.
Bootstrapping and testing now on 4.7 x86_64-linux, ok everywhere?
Bernd
PR rtl-optimization/53908
* df-problems.c (can_move_insns_across): Calls can clobber memory.
Index: gcc/df-problems.c
On 03/26/2012 06:03 PM, Andreas Schwab wrote:
Bernd Schmidt ber...@codesourcery.com writes:
Does 4.7 still have the failure at all?
Yes, see PR52573.
Well, I still think having both REG_DEAD and REG_UNUSED for the same reg
is bogus, but fixing that causes trouble in reg-stack. It seems
1701 - 1800 of 2315 matches
Mail list logo
