question about target info cache in resource.c
Hi all,
I would like to know if the attached patch resource-check.patch is a
good sanity check or not.
I have been working in reorg.c and running into trouble with the target
info cache in mark_target_live_regs, so I decided to write a patch that
checks consistency between cached values and recomputed values. Soon I
started running into issues that were unrelated to my changes in reorg.c.
As an example of the kind of situations the sanity check detects,
consider fixed-bit.c.212r.alignments. During pass_machine_reorg, the
following scenario happens:
1. a copy of insn 78 is imported into the delay slot of jump_insn 14.
(insn 106 13 49
/scratch/vries/henry7/mips/src/gcc-trunk-4.5/libgcc/../gcc/config/fixed-bit.c:183
(sequence [
(jump_insn 14 13 78
/scratch/vries/henry7/mips/src/gcc-trunk-4.5/libgcc/../gcc/config/fixed-bit.c:183
(set (pc)
(if_then_else (ne (reg:SI 2 $2 [200])
(const_int 0 [0x0]))
(label_ref:SI 105)
(pc))) 442 {*branch_equalitysi_micromips}
(expr_list:REG_DEAD (reg:SI 2 $2 [200])
(expr_list:REG_BR_PROB (const_int 6100 [0x17d4])
(nil)))
-> 105)
(insn/s 78 14 49 (set (reg:SI 3 $3 [orig:196 z+4 ] [196])
(const_int 0 [0x0])) 284 {*movsi_internal} (nil))
]) -1 (nil))
It's a copy since jump_insn 14 does not own the thread containing insn
78. The copy is marked with INSN_FROM_TARGET_P (insn/s) to indicate that
it was imported from the target of the jump.
2. we call mark_target_live_regs for insn 17. We scan all insn from the
start of the function to insn 17. We ignore however the copy of insn 78,
since it's marked with INSN_FROM_TARGET_P, so we conclude that $3 is not
live at insn 17. This info is stored in the target info cache.
3. redundant_insn finds that the original insn 78 is redundant (since
the copy of insn 78 occurs on all paths towards insn 78) and decides to
remove the original. The INSN_FROM_TARGET_P of the copy is cleared, to
indicate that the $3 is now live on the fall-through path of jump_insn
14 as well.
4. we call mark_target_live_regs for insn 17 again. We get the value
from the cache and conclude that $3 is not live at insn 17. Then my
patch recomputes the live info, which now takes the copy of insn 78 into
account since INSN_FROM_TARGET_P has been cleared, and concludes that $3
is live. And we assert.
The following fix makes sure that the cached live info is invalidated:
...
@@ -1865,6 +1880,7 @@ redundant_insn (rtx insn, rtx target, rt
{
/* Show that this insn will be used in the sequel. */
INSN_FROM_TARGET_P (candidate) = 0;
+ incr_ticks_for_insn (candidate);
return candidate;
}
...
and the assert is not triggered anymore.
So my questions are:
- is the consistency check correct? Does it make sense to fix all the
cases where it triggers?
- Is my analysis of the example and the fix correct?
Thanks,
- Tom
Index: gcc/resource.c
===
--- gcc/resource.c (revision 310935)
+++ gcc/resource.c (working copy)
@@ -878,6 +878,12 @@ mark_target_live_regs (rtx insns, rtx ta
rtx jump_insn = 0;
rtx jump_target;
HARD_REG_SET scratch;
+#if defined ENABLE_RUNTIME_CHECKING
+ HARD_REG_SET cached;
+ bool cached_valid = false;
+ int fb = -1;
+#endif
+
struct resources set, needed;
/* Handle end of function. */
@@ -918,6 +924,13 @@ mark_target_live_regs (rtx insns, rtx ta
if (b == -1)
b = find_basic_block (target, MAX_DELAY_SLOT_LIVE_SEARCH);
+#if defined ENABLE_RUNTIME_CHECKING
+ else
+{
+ fb = find_basic_block (target, MAX_DELAY_SLOT_LIVE_SEARCH);
+ gcc_assert (fb == -1 || fb == b);
+}
+#endif
if (target_hash_table != NULL)
{
@@ -927,8 +940,13 @@ mark_target_live_regs (rtx insns, rtx ta
update it below. */
if (b == tinfo->block && b != -1 && tinfo->bb_tick == bb_ticks[b])
{
+#if defined ENABLE_RUNTIME_CHECKING
+ cached_valid = true;
+ COPY_HARD_REG_SET (cached, tinfo->live_regs);
+#else
COPY_HARD_REG_SET (res->regs, tinfo->live_regs);
return;
+#endif
}
}
else
@@ -1126,6 +1144,10 @@ mark_target_live_regs (rtx insns, rtx ta
{
COPY_HARD_REG_SET (tinfo->live_regs, res->regs);
}
+#if defined ENABLE_RUNTIME_CHECKING
+ if (cached_valid)
+gcc_assert (hard_reg_set_equal_p (cached, tinfo->live_regs));
+#endif
}
/* Initialize the resources required by mark_target_live_regs ().
;; Function __ussubudq3 (__ussubudq3)
(note 1 0 6 NOTE_INSN_DELETED)
(note 6 1 80 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 80 6 4 2 NOTE_INSN_PROLOGUE_END)
(note 4 80 9 2 NOTE_INSN_FUNCTION_BEG)
(debug_insn 9 4 11 2
/scratch/vries/henry7/mips/src/gcc-trunk-4.5/libgcc/../gcc/config/fixed-bit.c:180
(var_location:
Re: Unrecognized option '-Wl,-rpath' for jv-convert
On 01/10/2011 06:40 PM, Ralf Wildenhues wrote: * Andrew Haley wrote on Fri, Jan 07, 2011 at 10:24:53AM CET: On 01/06/2011 09:28 PM, Gerald Pfeifer wrote: On Thu, 6 Jan 2011, Ralf Wildenhues wrote: Does passing '-Wl,-rpath -Wl,/foo' to gcj work for a small example program for you? I played around, and modifying the failing command line (that is, with all those -B, -L,... options) I still got the same failure. Note, if I remove -Wl,-rpath from that invocation, the failure is still the same, so that seems to come from gcj itself? It looks as though the -rpath arg isn't being passed correctly. I just can't figure out why this should be different on bsd. I think this just needs to be debugged. It should be pretty obvious what's happening. This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42524 aka http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21206 Ah, yes. It seems I approved the fix for this in2006, but it never went in. Andrew.
Plus Reload
Hi, I have a question regarding Plus reload situation I ran into in my port (which was taken from branch 4.6): I got the following insn: Set d1 (plus r1 -96). d1 and r1 are 2 registers from different classes. The reload (which take place at: reload1.c , gen_reload(out = d1, in = (plus r1 -96)) try 3 options: 1. switch the plus operands: set d1 (plus -96 r1) 2. split into 2 insns - reload the const to d1 and then add r1: set d1 -96 set d1 (plus d1 r1) 3. split into 2 insns - copy r1 to d1 and then add the const: set d1 r1 set d1 (plus d1 -96) GCC tries generating the 1st option - and fails since no valid pattern is found. Then it tries generating the 2nd option and fails once again, since no valid pattern is found. Then it tries generating the 3rd option without constraint validity check(emit_insn_if_valid_for_reload) like the first 2 attempts, and creates a new insn which will later fail since it's not satisfying it's constraints. My question is: why is GCC certain that one of those 3 attempts must work? In my case, all 3 resulted insns are not supported by the architecture. Thanks, Gidi.
Re: question about target info cache in resource.c
Tom de Vries writes:
> The following fix makes sure that the cached live info is invalidated:
> ...
> @@ -1865,6 +1880,7 @@ redundant_insn (rtx insn, rtx target, rt
> {
> /* Show that this insn will be used in the sequel. */
> INSN_FROM_TARGET_P (candidate) = 0;
> + incr_ticks_for_insn (candidate);
> return candidate;
> }
>
> ...
> and the assert is not triggered anymore.
>
> So my questions are:
> - is the consistency check correct? Does it make sense to fix all the
> cases where it triggers?
> - Is my analysis of the example and the fix correct?
Sounds reasonable to me.
Ian
Re: Plus Reload
Gidi Nave writes: > I have a question regarding Plus reload situation I ran into in my > port (which was taken from branch 4.6): > > I got the following insn: Set d1 (plus r1 -96). > d1 and r1 are 2 registers from different classes. > > The reload (which take place at: reload1.c , gen_reload(out = d1, in = > (plus r1 -96)) try 3 options: > > 1. switch the plus operands: > set d1 (plus -96 r1) > > 2. split into 2 insns - reload the const to d1 and then add r1: > set d1 -96 > set d1 (plus d1 r1) > > 3. split into 2 insns - copy r1 to d1 and then add the const: > set d1 r1 > set d1 (plus d1 -96) > > GCC tries generating the 1st option - and fails since no valid pattern is > found. > Then it tries generating the 2nd option and fails once again, since no > valid pattern is found. > Then it tries generating the 3rd option without constraint validity > check(emit_insn_if_valid_for_reload) like the first 2 attempts, > and creates a new insn which will later fail since it's not satisfying > it's constraints. > > My question is: why is GCC certain that one of those 3 attempts must work? > In my case, all 3 resulted insns are not supported by the architecture. What instructions are supported by your processor here? Ian
Re: Plus Reload
Hi Ian, Relevant instruction supported: add r,r,r add r,r unsigned add r,r, signed add d,d,d add d,d unsigned Thanks, Gal. On Tue, Jan 11, 2011 at 4:30 PM, Ian Lance Taylor wrote: > Gidi Nave writes: > >> I have a question regarding Plus reload situation I ran into in my >> port (which was taken from branch 4.6): >> >> I got the following insn: Set d1 (plus r1 -96). >> d1 and r1 are 2 registers from different classes. >> >> The reload (which take place at: reload1.c , gen_reload(out = d1, in = >> (plus r1 -96)) try 3 options: >> >> 1. switch the plus operands: >> set d1 (plus -96 r1) >> >> 2. split into 2 insns - reload the const to d1 and then add r1: >> set d1 -96 >> set d1 (plus d1 r1) >> >> 3. split into 2 insns - copy r1 to d1 and then add the const: >> set d1 r1 >> set d1 (plus d1 -96) >> >> GCC tries generating the 1st option - and fails since no valid pattern is >> found. >> Then it tries generating the 2nd option and fails once again, since no >> valid pattern is found. >> Then it tries generating the 3rd option without constraint validity >> check(emit_insn_if_valid_for_reload) like the first 2 attempts, >> and creates a new insn which will later fail since it's not satisfying >> it's constraints. >> >> My question is: why is GCC certain that one of those 3 attempts must work? >> In my case, all 3 resulted insns are not supported by the architecture. > > What instructions are supported by your processor here? > > Ian >
Re: Plus Reload
oh, I forgot: move d,r(d = r) On Tue, Jan 11, 2011 at 4:59 PM, Gidi Nave wrote: > Hi Ian, > > Relevant instruction supported: > > add r,r,r > add r,r unsigned > add r,r, signed > add d,d,d > add d,d unsigned > > Thanks, > Gal. > > > On Tue, Jan 11, 2011 at 4:30 PM, Ian Lance Taylor wrote: >> Gidi Nave writes: >> >>> I have a question regarding Plus reload situation I ran into in my >>> port (which was taken from branch 4.6): >>> >>> I got the following insn: Set d1 (plus r1 -96). >>> d1 and r1 are 2 registers from different classes. >>> >>> The reload (which take place at: reload1.c , gen_reload(out = d1, in = >>> (plus r1 -96)) try 3 options: >>> >>> 1. switch the plus operands: >>> set d1 (plus -96 r1) >>> >>> 2. split into 2 insns - reload the const to d1 and then add r1: >>> set d1 -96 >>> set d1 (plus d1 r1) >>> >>> 3. split into 2 insns - copy r1 to d1 and then add the const: >>> set d1 r1 >>> set d1 (plus d1 -96) >>> >>> GCC tries generating the 1st option - and fails since no valid pattern is >>> found. >>> Then it tries generating the 2nd option and fails once again, since no >>> valid pattern is found. >>> Then it tries generating the 3rd option without constraint validity >>> check(emit_insn_if_valid_for_reload) like the first 2 attempts, >>> and creates a new insn which will later fail since it's not satisfying >>> it's constraints. >>> >>> My question is: why is GCC certain that one of those 3 attempts must work? >>> In my case, all 3 resulted insns are not supported by the architecture. >> >> What instructions are supported by your processor here? >> >> Ian >> >
Re: Plus Reload
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/11/11 07:59, Gidi Nave wrote: > Hi Ian, > > Relevant instruction supported: > > add r,r,r > add r,r unsigned > add r,r, signed > add d,d,d > add d,d unsigned You're probably going to need a secondary reload to deal with this case d = r + -const If you allocate another R register for the secondary reload, then you could generate R2 = -96 R2 = R1 + R2 D = R2 jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNLHhlAAoJEBRtltQi2kC7vAQH/0zJq9h2oVDzY4PaSME88H9P IPuy0RIfTZlmvMsZ2Uiik6bzacKgqgktMpc5b92JsF/XwgVOo98ehRq+x9I2+tMv /o/pnpqN/qaBXPcF96LG7CMkxthkUJFg6Frif2ewpF5XC8wX2F7Zp/zTAYj8tPUd KOEFKLSOL1jsKJGlqI1bmhp2LtwyqVVbXiSaJX0wNy40bn2v/FZz6PHV50///itr 1YHc4uS7nhODMNqY8JdyZW8lTOrg9CA73biQLlr63nqVFkwsSDCKoaq+kyZJjn9L vBS3QWz36KMjVgNtY9pMXDLP2O93c++5tTpn9uXEgsCLO/e1O1cT3Z3ILaj7Dlc= =DLmt -END PGP SIGNATURE-
Re: Plus Reload
Gidi Nave writes: > On Tue, Jan 11, 2011 at 4:30 PM, Ian Lance Taylor wrote: >> Gidi Nave writes: >> >>> I have a question regarding Plus reload situation I ran into in my >>> port (which was taken from branch 4.6): >>> >>> I got the following insn: Set d1 (plus r1 -96). >>> d1 and r1 are 2 registers from different classes. >>> >>> The reload (which take place at: reload1.c , gen_reload(out = d1, in = >>> (plus r1 -96)) try 3 options: >>> >>> 1. switch the plus operands: >>> set d1 (plus -96 r1) >>> >>> 2. split into 2 insns - reload the const to d1 and then add r1: >>> set d1 -96 >>> set d1 (plus d1 r1) >>> >>> 3. split into 2 insns - copy r1 to d1 and then add the const: >>> set d1 r1 >>> set d1 (plus d1 -96) >>> >>> GCC tries generating the 1st option - and fails since no valid pattern is >>> found. >>> Then it tries generating the 2nd option and fails once again, since no >>> valid pattern is found. >>> Then it tries generating the 3rd option without constraint validity >>> check(emit_insn_if_valid_for_reload) like the first 2 attempts, >>> and creates a new insn which will later fail since it's not satisfying >>> it's constraints. >>> >>> My question is: why is GCC certain that one of those 3 attempts must work? >>> In my case, all 3 resulted insns are not supported by the architecture. >> >> What instructions are supported by your processor here? > > Relevant instruction supported: > > add r,r,r > add r,r unsigned > add r,r, signed > add d,d,d > add d,d unsigned So why doesn't d1 = d1 + -96 match the last instruction there? Ian
Re: register allocation
On 01/03/2011 10:41 AM, Jeff Law wrote: On 12/27/10 08:43, roy rosen wrote: I'd recommend to try ira-improv branch. I think that part of the problem is in usage of cover classes. The branch removes the cover classes and permits IRA to use intersected register classes and that helps to assign better hard registers. Sorry for the delay with the answer. I was on vacation last week. I tried now this branch and got better results for some cases but still in other cases I get lots of redundent register copies. I might be missing something from the gcc history but I wonder why do we need to limit the coloring stage to select a hard reg from a class that was chosen by a prior stage. In some cases, using all hard registers could improve the allocation. For example, usage of a pseudo for transferring value from one memory to another is such a case. In this case, we could use general hard register or floating hard registers if there are no free general hard registers. But in the most cases, usage of all hard registers is terrible idea for coloring because it results in wrong pseudos spilling. For example, if usage of floating point hard register is less profitable than memory, although it will never get floating point hard register in function assign_hard_reg whose decision is based on costs, we will still put the pseudo as colorable on the stack because even if there are not enough general hard register, CB algorithm still count it as colorable because there are floating point hard registers available. The order of pseudos on the stack actually defines what pseudos will be spilled. Also original CB works on non-intersected register classes. Those are reasons for the current IRA implementation. It was a design decision with the introduction of IRA. It made certain problems easier to resolve at the time and in reality, most of the time the set of legitimate and profitable hard registers for a given pseudo maps to a register class reasonably well. Why not simply put in the interference graph edges for all registers which are not possible for a pseudo and let the coloring algorithm select the best hard reg. It is already implemented but in more efficient way through macro ALLOCNO_AVAILABLE_REGS_NUMS. That's largely what the ira-improv branch does. Register classes at that point are used primarily to drive the costing model. In other words, ira-improv permits CB works on intersected register classess and do better allocation for the 1st example above.
Re: Plus Reload
because it's:add d,d unsigned we don't have: add d,d signed and in this case we need: d = r + (-96) On Tue, Jan 11, 2011 at 5:34 PM, Ian Lance Taylor wrote: > Gidi Nave writes: > >> On Tue, Jan 11, 2011 at 4:30 PM, Ian Lance Taylor wrote: >>> Gidi Nave writes: >>> I have a question regarding Plus reload situation I ran into in my port (which was taken from branch 4.6): I got the following insn: Set d1 (plus r1 -96). d1 and r1 are 2 registers from different classes. The reload (which take place at: reload1.c , gen_reload(out = d1, in = (plus r1 -96)) try 3 options: 1. switch the plus operands: set d1 (plus -96 r1) 2. split into 2 insns - reload the const to d1 and then add r1: set d1 -96 set d1 (plus d1 r1) 3. split into 2 insns - copy r1 to d1 and then add the const: set d1 r1 set d1 (plus d1 -96) GCC tries generating the 1st option - and fails since no valid pattern is found. Then it tries generating the 2nd option and fails once again, since no valid pattern is found. Then it tries generating the 3rd option without constraint validity check(emit_insn_if_valid_for_reload) like the first 2 attempts, and creates a new insn which will later fail since it's not satisfying it's constraints. My question is: why is GCC certain that one of those 3 attempts must work? In my case, all 3 resulted insns are not supported by the architecture. >>> >>> What instructions are supported by your processor here? >> >> Relevant instruction supported: >> >> add r,r,r >> add r,r unsigned >> add r,r, signed >> add d,d,d >> add d,d unsigned > > So why doesn't d1 = d1 + -96 match the last instruction there? > > Ian >
Re: register allocation
On 01/05/2011 09:44 AM, roy rosen wrote: 2011/1/3 Jeff Law: On 12/27/10 08:43, roy rosen wrote: I'd recommend to try ira-improv branch. I think that part of the problem is in usage of cover classes. The branch removes the cover classes and permits IRA to use intersected register classes and that helps to assign better hard registers. I tried now this branch and got better results for some cases but still in other cases I get lots of redundent register copies. I might be missing something from the gcc history but I wonder why do we need to limit the coloring stage to select a hard reg from a class that was chosen by a prior stage. It was a design decision with the introduction of IRA. It made certain problems easier to resolve at the time and in reality, most of the time the set of legitimate and profitable hard registers for a given pseudo maps to a register class reasonably well. Why not simply put in the interference graph edges for all registers which are not possible for a pseudo and let the coloring algorithm select the best hard reg. That's largely what the ira-improv branch does. Register classes at that point are used primarily to drive the costing model. Actually, I tried on this branch disabling the improve_allocation function and now it is doing a great job. For some reason the improve_allocation function only damaged the good allocation that was done. This function is pretty straight forward. It always improve allocation cost in given cost model. So either it only seems that the code is worse or the cost model is wrong for some reasons (it might be wrong definitions of target cost macros or the IRA cost model is inadequate). It is hard to say without more information. You could send me IRA dump with and without improve_allocation. You might want send the dumps only for me if you want keep confidentiality about you port. In order to look at that I am trying to understand the conflict table: I see ;; a3(r255,l0) conflicts: a4(r243,l0) a6(r129,l0) a8(r126,l0) a9(r254,l0) a10(r256,l0) a11(r257,l0) a12(r291,w0,l0) a12(r291,w1,l0) a13(r316,w0,l0) a13(r316,w1,l0) a14(r318,w0,l0) a14(r318,w1,l0) a15(r319,w0,l0) a15(r319,w1,l0) a16(r321,w0,l0) a16(r321,w1,l0) a5(r253,l0) a7(r252,l0) a17(r261,l0) ;; total conflict hard regs: 53 ;; conflict hard regs: 53 I see here conflicts of the pseudo with other pseudos and conflict with a hard reg - all are result of live range data. How is the constraint data which limits a pseudo in an insn to be of a certain class gets into this table? Constraints defines profitable allocno class (for example, in one insn the pseudo should be in floating point hard register and in many others it should be in general hard registers. In this case IRA most probably will use general register class for the allocno). But only reload pass really deals with constraints. I have expected also all hard regs which are not allowed for this pseudo because of constraints in the insns to be also in the conflict table. I guess I miss something... IRA reports only conflicting hard registers from allocno class to keep this list short. If it isn't there then how is it guranteed that the pseudo would be allocated to a hard reg which is allowed by the constraints?
Re: Plus Reload
Gidi Nave writes: > On Tue, Jan 11, 2011 at 5:34 PM, Ian Lance Taylor wrote: > >> So why doesn't d1 = d1 + -96 match the last instruction there? >> > because it's:add d,d unsigned > we don't have: add d,d signed > > and in this case we need: d = r + (-96) (Please don't top-post on this mailing list. Thanks.) Addition of signed and unsigned numbers is the same operation at the machine level. Are there limitations on the signed value? If so, is there is a sub instruction? Ian
gcc-4.4-20110111 is now available
Snapshot gcc-4.4-20110111 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110111/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 168682 You'll find: gcc-4.4-20110111.tar.bz2 Complete GCC (includes all of below) MD5=52e4a2271bf9468e154ce43ed59f51a7 SHA1=415fc283bfd9f89ce8350a52e04de5be1acbd422 gcc-core-4.4-20110111.tar.bz2C front end and core compiler MD5=5b46b4447e280662e502093b4c00a099 SHA1=37dfa9ba3a518aa88a1eb7186c46f2658a9cc820 gcc-ada-4.4-20110111.tar.bz2 Ada front end and runtime MD5=0a02f1f2ce55f39bbccfab4eef3c3f22 SHA1=8806714ce8c9a71a32824f9f133fe5a73865cd40 gcc-fortran-4.4-20110111.tar.bz2 Fortran front end and runtime MD5=32cf39f9762ad645c15668334dd4fdf9 SHA1=1fb8bc6bb77d5d44b854e92c84a5172712580daf gcc-g++-4.4-20110111.tar.bz2 C++ front end and runtime MD5=53dce010b10f0bd6e6ca2a60fe99c945 SHA1=ce3a83b4e16f3b4450ff648c0abdcb28f87ceda0 gcc-go-4.4-20110111.tar.bz2 Go front end and runtime MD5=e64faa0a9403df985a0a50f2638573fd SHA1=bbdcc8e880d10024adcf75ab463df0a5be9adcde gcc-java-4.4-20110111.tar.bz2Java front end and runtime MD5=85f26630f771dc94514251a5bf4ac8eb SHA1=b8fa7402c2b36fc2e4ece64bd70f9f056159a148 gcc-objc-4.4-20110111.tar.bz2Objective-C front end and runtime MD5=6da3b41acbb2a6184a2482c7c4b09070 SHA1=083863398a28efe26ff4f739a643348587bda6d7 gcc-testsuite-4.4-20110111.tar.bz2 The GCC testsuite MD5=765cc691154be58239b038817f9f01c0 SHA1=bf8842b0025a4764a03fef2124c4224a1622ccfe Diffs from 4.4-20110104 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Find a new maintainer for option handling?
Dear Steering Committee: The current listed maintainer for option handling is: option handling Neil Booth n...@daikokuya.co.uk But I'm wondering if Neil is still active. There are no replies to my recent pings from that email address. The last recorded commit from him in GCC was on 2005-01-19, which was nearly 6 years ago. So I guess he might have not worked on GCC. If this is true, how about assigning a new maintainer for option handling? Regards, -- Jie Zhang
Re: Plus Reload
On Tue, Jan 11, 2011 at 7:22 PM, Ian Lance Taylor wrote: > Gidi Nave writes: > >> On Tue, Jan 11, 2011 at 5:34 PM, Ian Lance Taylor wrote: >> >>> So why doesn't d1 = d1 + -96 match the last instruction there? >>> >> because it's: add d,d unsigned >> we don't have: add d,d signed >> >> and in this case we need: d = r + (-96) > > (Please don't top-post on this mailing list. Thanks.) > > Addition of signed and unsigned numbers is the same operation at the > machine level. Are there limitations on the signed value? If so, is > there is a sub instruction? > > Ian > Hi Ian, There are limitation for the signed value for D class registers. There is a sub instruction for D registers, but it's limited to U5 (unsigned of 5 bits) which is not the case here. Thanks, Gidi.
Re: Plus Reload
Gidi Nave writes: > On Tue, Jan 11, 2011 at 7:22 PM, Ian Lance Taylor wrote: >> Gidi Nave writes: >> >>> On Tue, Jan 11, 2011 at 5:34 PM, Ian Lance Taylor wrote: >>> So why doesn't d1 = d1 + -96 match the last instruction there? >>> because it's: add d,d unsigned >>> we don't have: add d,d signed >>> >>> and in this case we need: d = r + (-96) >> >> Addition of signed and unsigned numbers is the same operation at the >> machine level. Are there limitations on the signed value? If so, is >> there is a sub instruction? > > There are limitation for the signed value for D class registers. > There is a sub instruction for D registers, but it's limited to U5 > (unsigned of 5 bits) which is not the case here. Thanks. Since we don't know the details of your processor, we could be more helpful if you provided this sort of information up front. It sounds like you are saying that there is no way to subtract 96 without using an extra register. Is that correct? If that is the case, then I agree with Jeff that you are going to need to define a secondary reload. Look at TARGET_SECONDARY_RELOAD in the docs. By the way, if the restrictions on addition (which you did not describe) are less severe than the restrictions on subtraction, then you should consider adjusting your frame pointer so that most stack slots are at a positive offset rather than a negative one. I don't know if that is what is going on here, though a negative offset is certainly unusual. Ian
Re: kfreebsd-gnu etc. issues
Hi Joseph I'll look at more detail at the other problems, but first it seems that non-Linux GNU targets are currently broken because many declarations that are not Linux-specific have been added to the Linux-specific sections of config.gcc. Should I wait untill your patch is merged to fix this? Btw, your patch overhauls linux.h but not i386/linux64.h which is in the same situation as you described. -- Robert Millan
