On 06/01/2011 05:35 PM, Georg-Johann Lay wrote:
> The reason for why a subreg of hardreg is there during reload is that
> on avr, r29:r28 is the frame pointer (word_mode is QI and Pmode is
> HI). Because in many places of the compiler, there are tests like "if
> (regno == FRAME_POINTER_REGNUM)", t
On 06/01/2011 06:06 PM, Georg-Johann Lay wrote:
> From the internals description, HARD_FRAME_POINTER_REGNUM appears to
> serve different purpose, and sources indicate that it is used similar,
> i.e. per regno == HARD_FRAME_POINTER_REGNUM instead if having a rtx or
> reg_class and test for overlaps
I think it's great that Richard was appointed. I also understand Vlad's
frustration and can't imagine why he isn't RA maintainer.
On 06/28/11 14:39, Richard Guenther wrote:
> We discussed the maintainer appointing process at the London GCC
> Gathering event, a summary can be looked up at the pdf a
On 07/11/11 13:27, Georg-Johann Lay wrote:
>>> IRA now propagates insn 7 into insn 8 so that in insn-output gcc runs
>>> into the gcc_unreachable() even though !reload_in_progress etc should
>>> keep IRA/reload from generating the insn.
That can't work because reload_in_progress isn't set during I
On 07/11/11 18:12, Georg-Johann Lay wrote:
> The reason is that IRA (or reload, don't see it from the dumps)
> combines the insns again to:
>
> (insn 29 31 24 2 (parallel [
> (set (reg:HI 24 r24 [49])
> (mult:HI (reg:HI 18 r18)
> (const_int 15 [0xf])
On 07/11/11 18:42, Bernd Schmidt wrote:
> On 07/11/11 18:12, Georg-Johann Lay wrote:
>> The reason is that IRA (or reload, don't see it from the dumps)
>> combines the insns again to:
>>
>> (insn 29 31 24 2 (parallel [
>> (set (reg:HI 24 r24 [49])
On 07/12/11 13:11, Georg-Johann Lay wrote:
> Not familiar with combine inerts, I'd like to know if
> it's low hanging fruit to teach insn combine to perform
> optimizations like the following.
>
> Suppose following C code, int = HI
>
> int y15;
> int x15;
>
> void qmul8_xy (char c, int x, int y)
On 07/19/11 23:33, Richard Henderson wrote:
> But after pass_partition_blocks, we run into trouble. There
> are no less than 4 other passes that add *new* crossing jumps
> without doing *any* of the subsequent fixups for less capable
> targets: pass_outof_cfg_layout_mode, pass_reorder_blocks,
> pa
g patch.
Bernd
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 177967)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2011-08-22 Bernd Schmidt
+
+ * config/c6x/c6x.md (indirect_jump_shadow): Tweak represent
On 09/22/11 16:40, Alan Modra wrote:
> The bootstrap breakage happens on libmudflap/mf-hooks1.c, compiling
> __wrap_malloc. Eliding some detail, this function starts off as
>
> void *__wrap_malloc (size_t c)
> {
> if (__mf_starting_p)
> return __real_malloc (c);
>
> The "if" is bb2, the si
On 09/29/11 16:43, Rahul Kharche wrote:
>
>> insn 882 : cc <- compare (r684, 0)
>> jump_insn 883 : if (cc != 0) goto insn 46
>> insn 49: r291 <- r684
>> ..
>> insn 46
>>
>> cc contains the result of subtracting 0 from r684; control flow goes to
>> insn_49 only if (cc == 0)
On 09/29/11 17:36, Jeff Law wrote:
> On 09/29/11 09:26, Bernd Schmidt wrote:
>> ISTR cse.c has some support for this.
> cprop.c -- see references to implicit_sets.
cse too: record_jump_equiv.
Bernd
On 10/07/11 09:50, BELBACHIR Selim wrote:
> (asm result)
>
> load d($C2),$R1 <--1st operand for comparison ctrl,readmem,nothing
> loadi 0,$C4 <- 2nd operand for comparison ctrl,nothing
> load d($C2+4),$R2 <--no data dependancies ctrl,readmem,nothing
> cmp $C4,$R1
On 11/04/11 15:37, Hans-Peter Nilsson wrote:
> On Thu, 3 Nov 2011, Iyer, Balaji V wrote:
>> Is it possible to make sure that the "LABELX" occurs right
>> after the "Call some_function" instruction (and the instruction
>> scheduler moves the label with the call INSN)? I insert the
>> label right aft
On 12/28/2011 07:13 PM, Michael Eager wrote:
> Hi --
>
> I've run into a problem with the MicroBlaze backend
> where it is not recognizing a return pattern. I'm
> trying to modify the back end to use the 'simple_return'
> pattern, rather than 'return', since MicroBlaze has
> exactly what the docu
On 03/25/2010 04:03 PM, Jie Zhang wrote:
> I just found that the current RTL code hoisting cannot optimize
>
> REG = ...
> if (cond)
> {
> r0 = REG;
>
> }
> else
> {
> r0 = REG;
> ...
> }
>
> to
>
>
> REG = ...
> r0 = REG;
> if (cond)
> {
>
> }
> else
>
On 04/01/2010 10:54 PM, Daniel Jacobowitz wrote:
> I'm debugging a Thumb-2 glibc build failure on trunk for
> arm-none-linux-gnueabi. I believe it's from Richard Earnshaw's
> 2010-02-01 patch for TLS patterns, which includes this:
>
> (define_insn "tls_load_dot_plus_four"
> [(set (match_operand
On 04/01/2010 11:08 PM, Daniel Jacobowitz wrote:
> (define_insn "tls_load_dot_plus_four"
> [(set (match_operand:SI 0 "register_operand" "=l,r")
> (mem:SI (unspec:SI [(match_operand:SI 1 "register_operand" "l,r")
> (const_int 4)
> (m
Ian Lance Taylor wrote:
> Jean Christophe Beyler writes:
>
>> All of these have an outer code of SET. Therefore, I'm not quite
>> positive of how I'm supposed to implement my rtx_cost function. Since
>> I don't seem to get a choice between a set 0xcb03 and a (plus 0xcafe
>> 5), how can I tell the
Ian Lance Taylor wrote:
> No, that makes no sense. What I'm suggesting is that we fix the stack
> offsets of all local variables before register allocation, based on a
> conservative assessment of how many registers will be saved on the
> stack.
The conservative assessment is that all pseudos go
Paolo Bonzini wrote:
> These are all the !SHIFT_COUNT_TRUNCATED targets.
>
> For 4.5 I would like to improve our RTL canonicalization so that no
> out-of-range shifts are ever in the RTL representation.
>
> This in turn means that the description given by SHIFT_COUNT_TRUNCATED
> must be exact. R
Joern Rennecke wrote:
For ARCompact, doloop loops in particular were interesting to
optimize, which is why I have a patch to loop-doloop.c in
svn://gcc.gnu.org/svn/gcc/branches/arc-4_4-branch :
2009-02-24 J"orn Rennecke
* loop-doloop.c (doloop_valid_p): Rename to:
(validize
Hi,
Rahul Kharche wrote:
I am trialing this patch on a private GCC port that I'm working on.
The patch works well with several test cases we have. However, fails
on the following
int
main ()
{
const int arr[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 };
int i;
for (i = 0; i < 10; i++)
{
On 04/27/2010 08:41 PM, Jonas Paulsson wrote:
>> I've recently been bitten by the lost-widening-multiplication-
>> when-in-loop issue myself, and noted it for revisit Some Day.
>> Fixing that by other means made a whopping 27% improvement for
>> the application where I saw it: a hot loop doing a M
On 06/02/2010 01:42 AM, Ian Lance Taylor wrote:
>> The 'this->' is needed when the current class and base class are both
>> templates and the name is declared in the base class, and not if it's
>> declared in the current class. That is not likely to happen in a
>> hurry while the convention is to
On 06/10/2010 10:37 PM, Jeff Law wrote:
>
> Compile the attached with -O2 on x86-unknown-linux-gnu and review the
> .ira dump for main()
>
> starting the processing of deferred insns
> ending the processing of deferred insns
> df_analyze called
> Building IRA IR
> starting the processing of defer
On 06/11/2010 06:32 PM, Jeff Law wrote:
> But shouldn't having an invariant form just decrease the priority
> for pseudo 59 to get a hard register? The NO_REGS preferencing will
> totally disable register allocation for pseudo 59.
And that's intended, because from the costs we've concluded that
On 06/14/2010 07:58 PM, Ian Lance Taylor wrote:
> "Amker.Cheng" writes:
>
>> Wondering whether possible to handle multi-word mode with more accuracy,
>> in either subreg or IRA pass?
>
> Yes, it is possible. What you need to do is to write a split which
> turns the mult:DI insn into an insn whi
On 06/15/2010 12:06 AM, Ian Lance Taylor wrote:
> Well, as you know, subregs have two meanings which look similar but
> are in fact entirely different. It's valid to set subregs of the same
> pseudo in parallel if the subregs represent different hard registers.
> It's not valid if the subregs rep
On 06/18/2010 08:38 AM, Joern Rennecke wrote:
> You are not only rejecting invalid pic constants, you reject everything
> that's not CONST_INT. That could also include a
> (const (unspec ...)) for some integer the target has to calculate after
> register allocation / frame layout.
Examples? I'v
On 06/18/10 09:41, Joern Rennecke wrote:
> I found in an as-yet unreleased port that I had to use an UNSPEC as a
> placeholder for the return address; it is conceivable that you want
> to express the location of return address as the sum of the stack pointer
> and an as-yet unknown constant integer
In PR43902, Jim has posted a patch to add support for widening
multiply-accumulate to tree-ssa-math-opts. They are represented as a
GIMPLE_SINGLE_RHS with a WIDEN_MULT_PLUS_EXPR tree which holds the
actual operands of the multiply-accumulate. I've modified this a bit so
that we now support gimple
On 06/22/2010 11:39 AM, Jakub Jelinek wrote:
> On Tue, Jun 22, 2010 at 11:34:30AM +0200, Richard Guenther wrote:
>> We should add support for a GIMPLE_TERNARY_RHS class.
>
> It hasn't been added before because ternary ops were considered rare
> (primarily just COND_EXPR). If they are no longer s
On 07/06/2010 10:39 PM, IainS wrote:
> I'd like to compile a complete list of targets affected by changes in
> emulated TLS.
>
> *-*-darwin*
> hppa64-hp-hpux11.11
> cris-*-elf
>
> I think also;
>
> *-*-mingw
> *-*-cygwin
>
> could people please add to the list/confirm as appropriate?
I'm prett
On 07/21/2010 03:06 PM, Steven Bosscher wrote:
> It looks like ~9% extra !true_dependence cases are found with cselib,
> with is not insignificant:
>
> situationcalls depends ratio
> with_cselib 186764 70463 0.377284
> asis 186764 76375 0.408939 (i.e. no cselib)
>
> On the o
On 07/21/2010 03:06 PM, Steven Bosscher wrote:
> 3. GCC now has better alias analysis than it used to, especially with
> the alias-exporting stuff that exports the GIMPLE points-to analysis
> results, but also just all the other little things that were
> contributed over the last 10 years (little t
On 08/08/2010 05:08 PM, Uros Bizjak wrote:
> So, you will be able to use --enable-frame-pointer configure option.
Or, presumably the -fno-omit-frame-pointer command line option?
Bernd
On 08/20/2010 10:51 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> Sometime I have to do
>>
>> int x = 0;
>>
>> to silence gcc from uninitialized warnings when I know it is
>> unnecessary. Is that a good idea to add
>>
>> int x __attribute__ ((uninitialized));
>>
>> to tell compiler that i
On 08/23/2010 08:05 PM, Mohamed Shafi wrote:
> sub.s32 srcdstGP, #imm16 // signed 16-bit register to immediate subtract
> sub.u32 srcdstGP, #imm16 // unsigned 16-bit register to immediate subtract
If you're using a bit to decide between these two, a better encoding
would be to just support a sing
On 08/24/2010 07:38 PM, Basile Starynkevitch wrote:
> * what is the preferred way of obtaining a sequence of small patches?
> svn diff -x -p gives one big *.diff file! Should we split it by hand?
> Are there other tools producing a sequence of small patches?
http://savannah.nongnu.org/projects/qui
Joern RENNECKE wrote:
For easier reviewing, I have attached the diff to the cfgcleanup version
previous to the patch backout.
Thanks. Let me see if I understood the problem - please correct me if I
describe anything incorrectly.
The previous cross jumping code didn't care about register liv
Ok... can someone explain to me how the generic vector extension is
supposed to work? I've added a few V2HImode operations to the Blackfin
backend (in a 3.4-based compiler), and now I'm getting aborts all over
the place because the compiler is trying to make V8HImode registers for
operations o
Daniel Berlin wrote:
We already update life info way too much, even without struct-equiv
(Before struct equiv, this was done because flow's dce relied on
register liveness, and we called it from everywhere under the sun,
usually deep within other functions nobody realized were doing it). I
can t
Joern RENNECKE wrote:
Because the new code as of December actually updated life information
incorrectly, the global updates that were done had also quite a lot of
work to do (and didn't really do it right, because of the presence of
fake edges).
Could you elaborate on the problem with fake e
Jim Wilson wrote:
I see that flow no longer uses loop_depth when computing REG_N_REFS, so
the original reason for the sched support seems to be gone.
Do we have a replacement for this heuristic?
Bernd
Does anyone know a good reason not to allow modes such as V2PDI? The
Blackfin has dual multiply accumulate to 40 bit registers, and of all
the iffy ways to describe that, something involving 2x40 bit vectors
seems the least ugly.
Or does anyone have a better idea about handling 40 bit modes i
Does anyone find the use of #line in insn-recog.c actually useful? It
seems to make debugging recog() impossible.
Bernd
Daniel Berlin wrote:
I wrote a lot of the current zone collector. Before that, Daniel
Berlin did a lot of work on it. I really don't think I have time to
mentor an SoC project (Daniel, do you, maybe?),
I do, in fact, have time to mentor such a project, and would be happy to
mentor it if you
Ian Lance Taylor wrote:
You should run any patch past Joern, though.
I'd hesitate to apply patches to default_secondary_reload. If your port
triggers any of the sanity checks, convert it to the new infrastructure,
as it provides a much better interface.
Bernd
Andreas Krebbel wrote:
when cse replaces registers in an insn it tries to avoid calls to
validate_change, what causes trouble in some situations.
From validate_canon_reg:
/* If replacing pseudo with hard reg or vice versa, ensure the
insn remains valid. Likewise if the insn has MATCH_
Joern RENNECKE wrote:
In http://gcc.gnu.org/ml/gcc/2006-06/msg00120.html, you wrote:
As fwprop is no longer on the table for 4.2, and as the vectorizer
improvements seem to have stalled due to a combination of lack of review
and Dorit's leave, I think it's time to declare 4.2 feature-complete.
Steven Bosscher wrote:
I don't see how I could do the same with the new scheme from the projects
page, which goes like this (quoted from that page):
-
For arithmetic, each hash table elt has the following slots:
* Operation. This is an rtx code.
* Mode.
* Operands 0,
Rask Ingemann Lambertsen wrote:
The constraints are not met because the constraint "d" is register class
DX_REGS consisting of register 4 and 5, and (reg:HI 5 dh) spans register 5
and 6. Also, HARD_REGNO_NREGS (5, HImode) returns 0.
The lreg and greg dumps provide the clue that reload got the mo
Fu, Chao-Ying wrote:
We are working on a project to add fixed-point arithmetic support to GCC.
A GCC project description page is available here
http://gcc.gnu.org/wiki/FixedPointArithmetic
and we will create a GCC branch in the near future. If you have
any suggestions or comments, please respo
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/27/2014 02:50 PM, Felix Yang wrote:
I find DCE in sched2 is disabled for C6X backend. Is this a
performance consideration? Or a GCC BUG?
As far as I remember, it's a problem due to how delayed instructions are
represented to the final scheduler. Just before that scheduling pass is
On 02/07/2012 07:42 PM, Henderson, Stuart wrote:
> Hi,
> I'm investigating the following ICE building the Blackfin compiler from trunk:
> /home/shender/gnu-upstream/toolchain/gcc-4.7/libgfortran/generated/eoshift1_4.c:
> In function ÃâËeoshift1Ãââ:
> /home/shender/gnu-upstream/toolchain/gcc-4.7/li
On 02/14/2012 07:12 PM, Henderson, Stuart wrote:
>> spill_failure does return for asms since we don't want to ICE on bad
>> user code. That's all that's going on here.
>
> ahh, thanks.
>
>> It sounds like ifcvt needs to be fixed. Your example:
>>> block 44:
>>> set cc = x;
>>> set cc = y; (*)
>>>
On 02/22/2012 01:23 PM, Henderson, Stuart wrote:
> The problem with noce_get_condition is that if the condition variable
> is a MODE_INT register it will return it and set earliest as the jump
> insn itself. I'm not sure why this is the case, but it seems like
> something we don't want to be doing
On 02/22/2012 05:15 PM, Henderson, Stuart wrote:
>> Make an exception for BImode and small_register_classes_for_mode_p
>> (BImode).
>
> Thanks Bernd.
>
> Would this be acceptable:
>
> diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
> index 8d81c89..e4e13ab 100644
> --- a/gcc/ifcvt.c
> +++ b/gcc/ifcvt.c
>
On 03/05/2012 05:24 PM, Peter Bigot wrote:
> And is there any reason (other than it doesn't seem to have been done
> before) to believe PSImode is the wrong way to support a
> general-purpose 20-bit integral type in gcc?
If you're using 4.7.0, it should be possible to use FRACTIONAL_INT_MODE
and g
On 03/09/2012 11:20 AM, Aurelien Buhrig wrote:
> Hi,
>
> It seems there is an issue around subreg:HI of PSI hardware register,
> which occurs either during expand or reload (GCC 4.6.1).
>
> For my big endian target,
> (subreg:HI (reg:PSI A0_REGNO) 0) is not representable but
> (subreg:HI (reg:PSI
On 03/09/2012 04:20 PM, Aurelien Buhrig wrote:
> I'm not used to work at tree level for now and it is unclear for me what
> part of the code should be tweaked. Can you tell me which part of the
> code you are fixing/looking at, so that I can have a better
> understanding of ptr_mode vs Pmode before
On 03/13/2012 12:41 AM, Andreas Schwab wrote:
> Andreas Schwab writes:
>
>> Ian Lance Taylor writes:
>>
>>> Andreas Schwab writes:
>>>
Ian Lance Taylor writes:
> But it also looks like the pattern should use a match_scratch.
It is also used as input in operand 2.
>>>
>>
On 03/26/2012 07:37 PM, Eric Botcazou wrote:
>> Does 4.7 still have the failure at all? I've checked with the 4.6
>> branch, and regrename gets confused because there's a REG_DEAD note for
>> the register, and another REG_UNUSED for the same reg. As far as I
>> remember, it used to be the case that
On 03/30/2012 10:37 AM, Richard Guenther wrote:
> On Fri, Mar 30, 2012 at 9:14 AM, Ludovic Courtès
> wrote:
>> Hi,
>>
>> Gabriel Dos Reis skribis:
>>
>>> I do not think people working on plugins have come up with a
>>> specification and an API they agree on.
>>
>> I think it’s wrong to consider p
On 04/04/2012 11:06 AM, Richard Guenther wrote:
> So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be combined
> by transitioning vec.h to a C++ template class, with proper GC support.
> (not sure that I can veto anything - heh)
I don't think I can veto anything, but I'll go on the
On 04/10/2012 11:39 PM, Miles Bader wrote:
> Torvald Riegel writes:
>> I hate to bring this up, but in my personal experience, getting started
>> with LLVM was _much_ easier than with GCC. LLVM is a much newer
>> codebase, so that's an advantage unrelated to the language.
>
> I dunno, I've some
On 04/11/2012 09:45 AM, Gabriel Dos Reis wrote:
> I have been having difficulty following the twists and the turns and
> the goal post moving.
> Are you essentially requiring to see GCC rewritten in C++ before we
> switch to C++?
Frankly, despite all this discussion, we still don't really know wha
On 04/11/2012 02:57 PM, Torvald Riegel wrote:
> However, the concern you raised is only one part of the problem. The
> other is that, put in a simplified way, GCC is competing with LLVM about
> new and/or non-fulltime-compiler developers. For me, it looks like LLVM
> is more appealing to them, an
On 04/11/2012 06:53 PM, Peter Bigot wrote:
> On Mon, Mar 5, 2012 at 10:38 AM, Bernd Schmidt
> wrote:
>> On 03/05/2012 05:24 PM, Peter Bigot wrote:
>>> And is there any reason (other than it doesn't seem to have been done
>>> before) to believe PSImode is the
On 04/27/2012 11:31 PM, Greg McGary wrote:
I'm working on a port that does loads& stores in two phases.
Every load/store is funneled through the intermediate registers "ld" and "st"
standing between memory and the rest of the register file.
Example:
ld=4(rB)
...
...
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:
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
&g
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 s
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 *n_re
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 constra
Count another vote for getting rid of GC.
Bernd
Ian Lance Taylor wrote:
Boris Boesler <[EMAIL PROTECTED]> writes:
The following code generators use FOR_EACH_BB[_REVERSE] in the
target machine dependent reorg pass:
- bfin
- frv
- ia64
- mt
- s390
Are these invalid code generators then? Or are we talki
Joern Rennecke wrote:
And @code{(subreg:SI (reg:DF 10) 0)} would be a natural way to express that
you are using the floating point register as a 32 bit integer register,
with writes clobbering the entire 64 bit of the register.
Yes, this is one possible definition. But there's no reason in this
Paolo Bonzini wrote:
SPE has patterns for
[(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "+r,m")
(subreg:SI (match_operand:SPE64TF 1 "register_operand" "r,r") 4))]
for example.
What are they trying to do? It's dubious for a number of reasons:
- SUBREG in the instruction patter
Joseph S. Myers wrote:
Yes. For SPE, the subregs used in these *frob_* patterns represent
concepts including the high-part of a register (only used by certain
instructions that treat registers as 64 bits) and a DImode value stored in
one 64-bit register (normal layout is in two) or a DFmode va
Mohamed Shafi wrote:
In cris i saw this patten
(define_insn "*andhi_lowpart"
[(set (strict_low_part
(match_operand:HI 0 "register_operand" "=r,r, r,r,r,r"))
(and:HI (match_operand:HI 1 "register_operand" "%0,0, 0,0,0,r")
(match_operand:HI 2 "genera
Mark Shinwell wrote:
> The bug is currently only exhibiting itself on a proprietary testcase
> when compiled for an ARM target and is extremely sensitive to the
> particular code involved. It arises as follows, using the same notation
> as in Richard's mail:
If you can't post the testcase, the be
Mark Shinwell wrote:
> These dumps are of course taken before the application of my patch.
>
> Hope that helps,
Thanks. I may have missed it in the previous mails, but which piece of
code exactly decides to use R9 for reload 0 of insn 5314?
Bernd
--
This footer brought to you by insane German
Mark Shinwell wrote:
> The relevant RTL instructions before reload are as follows. These
> correspond to points A, B and C respectively in my previous email.
I must admit I'm still stumbling in the dark a bit - this would be so
much easier to digest with a testcase.
The question I'm trying to an
Mark Shinwell wrote:
> As you say, one unusual thing about this situation must be the fact
> that the reload register is getting chosen by the code in
> push_reload heralded by "If this is an input reload and the operand
> contains a register that dies in this insn and is used nowhere else,
> see i
Mark Shinwell wrote:
> This code is guarded by
>
> /* I is nonneg if this reload used a register.
> If rld[r].reg_rtx is 0, this is an optional reload
> that we opted to ignore. */
>
> if (i >= 0 && rld[r].reg_rtx != 0)
>
> and in this [my original] case, i is negative (se
Mark Shinwell wrote:
> and the code following in emit_reload_insns? Perhaps if spill_reg_index
> took account of registers selected during find_reloads then this could
> be simplified too.
>
> So what do you think is the best approach to fix all of this? :-)
Sounds like you gave the answer your
Mark Shinwell wrote:
> Do you think it should be the case that, at the point below, _any_ reload
> with reg_rtx corresponding to a hard register should have the relevant
> bit set in reload_spill_index?
I think so. I'm attaching a patch below. It appears to have no effect
on all code I've tried
nchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
Index: ChangeLog
===
--- ChangeLog (revision 125680)
+++ ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2007-06-13 Bernd Schmidt <[EMAIL PROTECTED]>
+
Fu, Chao-Ying wrote:
> I attached a diff file for 14 files of the new structures
> and documents. You and other maintainers are welcome to
> check it. Thanks a lot!
>
> Note: 14 files are =>
> genmodes.c mode-classes.def machmode.def machmode.h tree.def tree.h
> tree.c rtl.def rtl.h rtl.c fixe
Fu, Chao-Ying wrote:
+ACCUM_MODE (HA, 2, 8, 7); /* s8.7 */
+ACCUM_MODE (SA, 4, 16, 15); /* s16.15 */
+ACCUM_MODE (DA, 8, 32, 31); /* s32.31 */
+ACCUM_MODE (TA, 16, 64, 63); /* s64.63 */
Lots of predefined types and modes in this patch. What about targets
with other requirements (the Blackfin h
Kenneth Zadeck wrote:
Paolo Bonzini wrote:
having the dead note there is asserting to the register allocator that
they are free to use that reg after the calll in any way that it wants
and there is a (small) possibility that is wrong.
IMO there is nothing wrong with this.
I agree with Roman.
Mark Shinwell wrote:
Bernd Schmidt wrote:
Mark Shinwell wrote:
Do you think it should be the case that, at the point below, _any_
reload
with reg_rtx corresponding to a hard register should have the relevant
bit set in reload_spill_index?
I think so. I'm attaching a patch below
Daniel Jacobowitz wrote:
Am I the only one who completely fails to see the point of the
spelling change? I realize that you have said you find negative
predicates confusing - I don't, but I do find changing predicates
confusing. I applaud cleaning up the definition and/or replacing it
with a ma
David Edelsohn wrote:
Leaving released branches as GPLv2 is not an option.
Dave> What, even *closed* release branches?
The comment referred to GCC 4.2. GCC 4.2 branch may not remain
under GPLv2. GCC 4.1 branch may not remain under GPLv2. Closing the GCC
4.2 branch is impractical -- w
Michael Matz wrote:
Apart from that I agree that in the case of conditional defs multiple ones
might reach a use. I disagree for partial defs, if one dominates the
other. For most cases (except register allocation) a partial def is just
a complete killing def, which happens to leave some co
Jie Zhang wrote:
libstdc++ tries to avoid link tests when configured with newlib. But I
saw this when working on bfin port gcc:
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... no
checking how to hardcode library paths into programs... immediat
Jie Zhang wrote:
But by design if gcc_no_link = no, link tests should be avoided.
??? I would have thought gcc_no_link = yes means link tests are avoided.
Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen
Sitz
101 - 200 of 215 matches
Mail list logo
