Re: Missing elements in VECTOR_CST
On Mon, 18 Sep 2006, Mark Mitchell wrote:
> Andrew Pinski wrote:
> > The documention on VECTOR_CST is not clear if we can have missing
> > elements in that the remaining elements are zero. Right we produce such
> > VECTOR_CST for things like:
> > #define vector __attribute__((vector_size(16) ))
> > vector int a = {1, 2};
> >
> > But is that valid? We currently produce a VECTOR_CST with just two
> > elements instead of 4. Should we always have the same number of
> > elements in a VECTOR_CST as there are elements in the vector type?
>
> I think it is reasonable for front-ends to elide initializers and to
> follow the usual C semantics that elided initializers are (a) zero, if
> the constant is appearing as an initializer for static storage, or (b)
> unspecified, "random" values elsewhere.
Maybe you didn't mean what I read, but it's not just "for static
storage". By my reading (of the May 6, 2005 ISO/IEC 9899:TC2
for reference), all items in arrays and named structure members
not mentioned in the initializer should be 0-initialized (the
"all subobjects that are not initialized explicitly shall be
initialized implicitly the same as objects that have static
storage duration" part in 6.7.8:19).
brgds, H-P
Re: Meaning of (set (reg:CC condition_codes_reg) (ge (op0) (op1)))
On Sat, 2 Sep 2006, Rask Ingemann Lambertsen wrote: >What does this instruction mean? > > (set (reg:CC 13 cc) > (ge (mem/c/i:HI (plus:HI (reg/f:HI 15 argp) > (const_int 2 [0x2])) [2 x+0 S2 A16]) > (const_int 0 [0x0]))) >... >The (reg:CC 13 cc) part is the condition code register. But I have no > idea what it means to set that register to a constant (such as > STORE_FLAG_VALUE). I'm not sure I understand the question correctly (answer being a bit on the obvious side), but for me the answer is "the truthvalue of (argp[1] > 0) in the representation the target uses for CCmode". It's not strictly STORE_FLAG_VALUE at this level; only when "translated" into an ordinary integer mode. When in CCmode it's just the condition code flags; whatever goes in reg 13 when being the (possibly implicit) target of that compare insn. Hope this helps. brgds, H-P
Re: REG_OK_STRICT and EXTRA_CONSTRAINT
On Fri, 25 Aug 2006, Paolo Bonzini wrote: > After I'm done with the base_reg_class changes, I will try > modifying address_operand to be something along the lines of your U > constraint: Yeah, that does sound like the real bug; nothing should be using non-strict checking after reload as address_operand seems to do. > This will also affect the 'p' constraint, and in the end address your > "FIXME: This is arguably a bug in gcc." Wow, I had that? I didn't think of looking at its *use* yesterday... been away from gcc for a while. > Of course, again, this is > subject to testing. I haven't everything set up for testing, but will try your change when that happens (no less than a week from now). > Thanks to Zack for discussing this on IRC and hypothesizing that this > may be a real bug in GCC. And thanks to you for looking into this! brgds, H-P
Re: REG_OK_STRICT and EXTRA_CONSTRAINT
On Thu, 24 Aug 2006, Paolo Bonzini wrote: > Anyway, I was not meaning to *not* account for anything, but just to > replace REG_OK_STRICT with checks on reload_in_progress and > reload_completed. I understand the semantics that you wanted for 'U'. > > The bug may be that in some cases, 'U' is checked for memory_address_p > instead of strict_memory_address_p even after reload, in particular when > it is recog.c that is constraining the operands. If so, not more buggy than other targets that use REG_OK_STRICT a bit more indirectly (like using REG_OK_FOR_BASE_P directly or indirectly in their EXTRA_CONSTRAINT or GO_IF_LEGITIMATE_ADDRESS). Some history I found on this change: http://gcc.gnu.org/ml/gcc-patches/2001-12/msg02585.html> http://gcc.gnu.org/ml/gcc-patches/2001-12/msg02501.html>. Sorry I don't remember more, in particular not where I got the idea to choose between strict_memory_address_p and memory_address_p. I had the flu at the time, so I might have actually found it up myself. :-) If the general replacement of REG_OK_STRICT is indeed reload_in_progress || reload_completed, then the substitution *should* of course be in principle be correct (as in: subject to testing. ;) brgds, H-P
Re: REG_OK_STRICT and EXTRA_CONSTRAINT
On Thu, 24 Aug 2006, Paolo Bonzini wrote: > Some ports, notably MMIX, are using different definitions of > EXTRA_CONSTRAINT depending on REG_OK_STRICT. This can be a bug, because > the same instruction may be considered invalid in reload.c and valid by > recog.c. When I wrote that code, accounting for REG_OK_STRICT was not a bug, but TRT. (I'm about two months behind on mailing list reading, so I guess things may have changed as things tend to do.) > So I would apply this patch to addressing-modes branch but I'd > appreciate advice: is the patch safe, or is there some case where > reload.c looks at constraints and reload_in_progress == 0? My opinion is that regtesting and checking that the same assembly is emitted before and after the patch would be sufficient testing... It's definitely not safe without. ;) brgds, H-P
Re: RFC: Message-ID to mailing list URL match
On Fri, 17 Feb 2006, Grigory Zagorodnev wrote: > For example cgi-bin/mesg.cgi script of mhonarc mail-to-html converter, > the one used by gcc.gnu.org, can "extract a message from an archive > based upon message-id" so having interface to this script would be > useful. Further the mail client may be taught to get this URL automatically. > > Any comment? IMHO sounds like a nice suggestion. (Though I'm weasely not committing to anything.) brgds, H-P
Re: Design a microcontroller for gcc
On Thu, 16 Feb 2006, Sylvain Munaut wrote: > Move/Load/Store without flag is no problem. But for add, to allow > multiword add, carry is needed and I can't make it optionnal. As I hinted, perhaps you can have the multiword carry a separate one from the flags carry, perhaps moved over with a separate instruction? Perhaps have a "load" variant that doesn't load; a "lea"? Perhaps it only does that when run just after a prefix instruction (that has another meaning before some other instruction)? (Look, there's your separate add and move instruction in one! :-) If it comes to that, I will go as far as suggesting that flags handling is more important than multiword add support. Really. (The latter will happen less frequently and can be performed with a few more instructions.) > But as you said, I could make the load/store take 3 args, either > load rD, rB(rA) > or > load rD, imm4(rA) > > with imm4 being between -16 and 15. That's not enough to cover a full stack frame, unfortunately. I suggest you find out a way to load an arbitrary integer into a register without touching flags (there's no point in having that touch flags) and then a way to add two registers without touching flags. Maybe it's sufficient with the first one, but I'm not willing to bet on it. > Another thing for memory. I can't make 8 bits access, the memory is 16 > bits wide and I can't change that, so 8 bits access will have to be done > in sw. That's ok. 8-bit accesses are desirable, but not a must and not as important as anything else I can think of. > Also, I could make the address given a word address or a byte address > (but then I would just drop the LSB since i don't support unaligned > access ... and the immediate in load/store would be each even between > -32 and 30). Stick with byte addresses. Really, really really. Word addresses used to be somehow supported, but there are many bugs and no other working port does it. Having the imm4 be bits 5..1 and bit 0 constant 0 is certainly the right thing to do for 16-bit-wide accesses. > Now the problem is to well describe to gcc what can be taken as an > immediate and what can't ... That's really not a problem, it's quite simple. brgds, H-P
Re: Design a microcontroller for gcc
On Wed, 15 Feb 2006, DJ Delorie wrote: I wrote: > > Anyway, at least keep a way to add reg+reg and reg+integer, load and > > store of memory and load of integer and address without condition > > code effects and your port has a chance to avoid the related bloat. > > At least, move/load/store shouldn't touch flags. I may have listed more operations than necessary, but the important bit is that you need to form arbitrary addresses in the stack frame without touching flags. If for any const_int N, (plus reg N) is a valid address for moves to and from memory that doesn't touch flags, then I suppose you don't *need* an "add" that doesn't touch flags. brgds, H-P
Re: Design a microcontroller for gcc
On Wed, 15 Feb 2006, Hans-Peter Nilsson wrote: > Unless I'm delirious (it's way past bedtime) I see a m32c port > and it's cc0-free. Is there a problem? I see, in the code in svn trunk the compares aren't optimized away yet. You must be having a lot of fun right now. ;-) brgds, H-P
Re: Design a microcontroller for gcc
On Wed, 15 Feb 2006, DJ Delorie wrote: > I hope I can stick with my cmp/jmp model and manage them myself still, > though, because there's a LOT of patterns in m32c where the set of > flags affected depends on which alternative you select, and most > patterns affect the flags in some (usually nonorthagonal) way. Unless I'm delirious (it's way past bedtime) I see a m32c port and it's cc0-free. Is there a problem? > Or is gcc going to start putting things between the cmp and jmp? Yes. At least reload wants to do that. The choice a port has is to either have cc-free reload insns (like i386) or keep the cc setter and user combined at least until after reload (cbranch, but you don't have to use the cbranchM4 name; you can do the combination to a cbranch-type insn in the CC user). Not my idea, so it's probably sane. :-) brgds, H-P PS. There may be other choices, but none that caught my attention.
Re: Design a microcontroller for gcc
On Wed, 15 Feb 2006, Hans-Peter Nilsson wrote: > FWIW, I use > peephole2s and condition code modes in CRIS w.i.p. ...and cbranch (cc setter + user in one combined insn) which are split after reload. brgds, H-P
Re: Design a microcontroller for gcc
On Wed, 15 Feb 2006, DJ Delorie wrote: > > BTW, carry-out from shifts is very rarely used in compiled code.) > Unless you've expanded SI shifts into a pair of HI shifts. > > > Besides what DJ said about performance (both pros and cons > > there), the problem is as I said with port complexity, because > > of the way you have to handle condition codes in gcc. > > Unless you tell gcc that the condition codes are hard register? No "unless" here. You either have a clobber or a set in a parallel with the main feature, and you lose out on all the single_set-directed optimizations if you put in a "set" early. > That's what m32c does; it has separate cmp/jmp and most opcodes set > flags, so I just set an attribute that says which flags are set by > each insn. Then, I can add a reorg pass to delete the cmps if the > previous insn that set the flags happened to set them right. A machine dependent reorg pass isn't something I'd recommend given that there are other possibilities. FWIW, I use peephole2s and condition code modes in CRIS w.i.p. Works ok, except for all the things that doesn't like insns with parallels that I have to weed out to get performance on par with the cc0 representation. brgds, H-P
Re: Design a microcontroller for gcc
On Thu, 16 Feb 2006, Sylvain Munaut wrote: > What I was thinking for the moment was to have : > - sign is always the msb of the last ALU output > - add/sub to modify all flags > - move/xor/and/not/or only affect zero (and sign) > - shift operations always affect carry and zero > - Have some specific instructions like compare and test, but theses >would only operate on registers (and not on immediate) No, really. Just use compare insns. (And perhaps some way for carry propagation for multi-word add/sub, if that mechanism interferes. BTW, carry-out from shifts is very rarely used in compiled code.) > What's so bad about have the flag as side-effects ? Besides what DJ said about performance (both pros and cons there), the problem is as I said with port complexity, because of the way you have to handle condition codes in gcc. (_Should_ now, _have_to_ in the future -- or actually now, as you say you need scheduling.) Flag setting really should be explicit, so with your way, you have to show that add and sub etc. also set condition codes. And that's where you notice the complexity in the port, because (partly because of gcc pecularities) unless you want to lose performancewise, you need to show that most of the time, the flag register result is just clobbered by those operations and not used. Anyway, at least keep a way to add reg+reg and reg+integer, load and store of memory and load of integer and address without condition code effects and your port has a chance to avoid the related bloat. Sorry, I won't spend the time to spell out the details. Whatever: if you're determined on your way to do it and won't take advice you asked for, by all means feel free. You _have_ been warned, though. brgds, H-P
Re: Design a microcontroller for gcc
On Wed, 15 Feb 2006, Sylvain Munaut wrote: > * 2 flags Carry & Zero for testing. I think most of your questions have been answered, so let me just add that if nothing else, the port will be much simplified if you make sure that only specific compare instructions set condition codes, i.e. not as a nice side-effect of move, add and sub - or at least make such condition-code side-effects optional. It depends on too many undisclosed details like pipeline restrictions to say whether performance is generally better or worse, but I can tell for sure that the GCC port will be simpler with a specific set of condition-code setting insns. BTW, it depends on the compare (and branch) instructions whether just two flags are sufficient. brgds, H-P
Re: Since r110852: Mainline broken for VAX (cc0 target)
On Sun, 12 Feb 2006, David Fang wrote: > > > And now: How do you actually find the PRs? I seem to wrongly use > > > Bugzilla's search engine. I submitted "int_mode_for_mode" into the > > > "Enter a bug # or some search terms" box of > > > http://gcc.gnu.org/bugzilla/ , which didn't find anything. I don't > > > really feel like wasting your time with doing my homework... > > > > Well I look at all bug reports that come in so I knew this one was > > already filed. Other than that searching for int_mode_for_mode will > > help. Also searching for cc0 can also find it too. > > I used to find Zarro Boogs, until I remembered to search for > "ALL term_to_search_for". The keyword 'ALL' is kind of important. Apparently it's not obvious, so I recommend always using the bugzilla "Advanced search" and "a Comment [contains the string]" and search for some key item in the ICE message. (That's what I did, using int_mode_for_mode, before filing PR 26232.) brgds, H-P PS. No, I don't know why the simple "some search terms" doesn't work.
Re: cannot find -lm
On Tue, 24 Jan 2006, Eric Fisher wrote: > ld: cannot find -lm > collect2: ld returned 1 exit status > How can I get it? Port newlib. It's simple enough. brgds, H-P
Re: Status and rationale for toplevel bootstrap (was Re: Example of debugging GCC with toplevel bootstrap)
On Mon, 16 Jan 2006, DJ Delorie wrote: > Two copies of gcc, both configured for the same target and built from > the same sources, should produce identical objects regardless of how > they are built or what they run on. For the record, this unfortunately isn't so, at least wasn't weeks ago, comparing cross-compiler output from a "32-bit host" (i686-) and a "64-bit host" (x64_64-) for a 32-bit target (cris-), at least not when compiling 64-bit code (i.e. "long long" on this target). brgds, H-P
Re: What does this character mean in DLX's md file?
On Thu, 19 Jan 2006, Paolo Bonzini wrote: > > (define_insn "" ... > > "%C1f\\t%2,%3" > > I don't know the meaning of the > > numeric character "1" between "%C" and "f" in the output template. > > It means that operand 1 (the signed_comparison_operator) is passed to > the dlx.c routine. Likewise for %2 and %3. The "routine" in question being the expansion of the target macro PRINT_OPERAND. See the documentation. brgds, H-P
Re: on data depenence
On Wed, 28 Dec 2005, Liu Haibin wrote:
(I'm this far ^ behind on reading mailing lists.)
It's likely that you have since long noticed, but in case not:
> I got a dump of sha.c.27.flow2 from gcc 3.4.1. I don't quite
> understand the LOG_LINKS of insn 498. LOG_LINKS in insn 498 shows that
> it has a data dependence (a read after write dependence) with insn 3.
> Why is it so? I don't see any dependence between "mov r14 r4" and
> "addi r3, r4, 28". The bottom is the whole dump of the basic block.
It says r14 (14), not r4 (4).
>
> (insn 3 4 11 0 (set (reg/v/f:SI 14 r14 [orig:46 sha_info ] [46])
> (reg:SI 4 r4 [ sha_info ])) 8 {movsi_internal} (nil)
> (expr_list:REG_DEAD (reg:SI 4 r4 [ sha_info ])
> (nil)))
Set of R14.
>
>
> (insn 498 375 560 0 (set (reg/f:SI 3 r3 [235])
> (plus:SI (reg/v/f:SI 14 r14 [orig:46 sha_info ] [46])
> (const_int 28 [0x1c]))) 20 {addsi3} (insn_list 3 (nil))
> (nil))
Use of R14.
Or maybe you meant something else?
brgds, H-P
Re: RFC: peephole vs RTX_FRAME_RELATED_P
On Mon, 2 Jan 2006, Ian Lance Taylor wrote: > When did the bogus split > happen? Sorry, I didn't answer this question and now the gdb session is gone. Hopefully the answer isn't that important given RTH's comment? I'd guess reorg. brgds, H-P
Re: RFC: peephole vs RTX_FRAME_RELATED_P
On Mon, 2 Jan 2006, Ian Lance Taylor wrote: > I wouldn't expect to see any insns with RTX_FRAME_RELATED_P set before > the prologue and epilogue are threaded in the flow2 pass. So combine > shouldn't be an issue. And flow2 calls split_all_insns before the > prologue and epilogue insns are threaded. When did the bogus split > happen? Huh, I emitted RTL prologue insns that were themselves candidates for splitting (without any transformations). I thought the same could happen for RTL transformations but it seems peephole2 (and stack adjustments, but that's not applicable to CRIS) was the only "real" candidate. So, there's just an undocumented implicit requirement that nothing emitted as RTL prologue (accidentally) matches a splitter. brgds, H-P
Re: RFC: peephole vs RTX_FRAME_RELATED_P
On Mon, 19 Dec 2005, Richard Henderson wrote: > I think that this is all complicated enough that we should > simply deny peepholing insns with RTX_FRAME_RELATED_P set. I was just bitten by the same behavior for define_split. Should the same go for define_splits and maybe also as a guard test for combine? Maybe a utility function to use by all insn transformations? brgds, H-P
Re: RFC: combine simplification change: 2-for-2-with-lesser-cost
> Date: Tue, 20 Dec 2005 12:34:30 +0100 > From: Hans-Peter Nilsson <[EMAIL PROTECTED]> > I want it done there *only* because that's what it does for the > similar but even more complex cc0 code and because combine does > multi-insn simplifications in general. Never mind, I think I have a reasonably small and simple patch for cse.c:find_comparison_args that lets it do what everybody expects it to do. brgds, H-P
Re: RFC: combine simplification change: 2-for-2-with-lesser-cost
> Date: Tue, 20 Dec 2005 11:13:06 +0100 (CET) > From: Steven Bosscher <[EMAIL PROTECTED]> > You really have to wonder if cleaning up this jump is a job combine > should be doing. I want it done there *only* because that's what it does for the similar but even more complex cc0 code and because combine does multi-insn simplifications in general. I suggest not being hung up on it being a jump that's simplified. Anyhow, I'd like to disconnect the un-cc0-ification of the CRIS port while retaining performance, from overhaul of GCC passes as much as possible, please, however TRT the overhaul may be. > I would have thought we'd clean this up _before_ > combine Me too... Might be a simple oversight somewhere. I'll have a closer look; seems at a glance that gcse thinks it does this. > (and no, I don't mean the tree optimizers, but e.g. CSE, or jump > bypassing (even though the latter doesn't work for critical > edges)). FWIW, jump bypassing doesn't do anything transformationwise but calling the usual cfgcleanup things. CFG apparently doesn't perform the necessary kind of simplifications. See rest_of_handle_jump2. > Are > there other cases, you think, where we fail to combine 2 insns into 2 > cheaper ones?? I don't know, but as combine seems to be the only pass performing inter-insn simplifications, I'd guess so. brgds, H-P
RFC: combine simplification change: 2-for-2-with-lesser-cost
I'd like for combine to perform the following simplification:
(insn 14 13 16 0 /home/hp/combined/combined/gcc/config/cris/arit.c:228
(parallel [
(set (reg/v:SI 27 [ b.67 ])
(abs:SI (reg/v:SI 47 [ b ])))
(clobber (reg:CC 19 dccr))
]) 158 {abssi2} (insn_list:REG_DEP_TRUE 7 (nil))
(expr_list:REG_UNUSED (reg:CC 19 dccr)
(nil)))
(jump_insn 17 16 19 0 /home/hp/combined/combined/gcc/config/cris/arit.c:178
(parallel [
(set (pc)
(if_then_else (ge (abs:SI (reg/v:SI 47 [ b ]))
(const_int 0 [0x0]))
(label_ref 24)
(pc)))
(clobber (reg:CC 19 dccr))
]) 1 {cris_cbranchsi4} (insn_list:REG_DEP_TRUE 14 (nil))
(expr_list:REG_UNUSED (reg:CC 19 dccr)
(expr_list:REG_BR_PROB (const_int 7900 [0x1edc])
(nil
into:
(insn 14 13 16 0 /home/hp/combined/combined/gcc/config/cris/arit.c:228
(parallel [
(set (reg/v:SI 27 [ b.67 ])
(abs:SI (reg/v:SI 47 [ b ])))
(clobber (reg:CC 19 dccr))
]) 158 {abssi2} (insn_list:REG_DEP_TRUE 7 (nil))
(expr_list:REG_UNUSED (reg:CC 19 dccr)
(nil)))
(jump_insn 17 16 19 0 /home/hp/combined/combined/gcc/config/cris/arit.c:178
(set (pc) (label_ref 24)) 1 {jump}
(insn_list:REG_DEP_TRUE 14 (nil)))
(beware, edited RTL.) However, it doesn't, as trading two for
two-with-a-lesser-cost is currently not done; comments mention
fear of recursion or oscillation. That shouldn't happen if the
rtx cost is considered and is nearly sane.
If you think this optimization is misplaced, I see no pass
*after* combine, that is expected to this perform
simplification. Maybe the SSA optimizations before this pass
should cover it, but they don't, at least not with 108225
compiling libgcc/_divsi3.o for cris-axis-linux-gnu (there's an
abs in a caller, with a < 0 test in an inlined function). This
function is the top pessimized for my non-cc0 CRIS wip. Anyway,
arguments like "no, do it in SSA" miss the point and will be
ignored; things have different shape at the RTL level and may
not be apparent in SSA. (Yes, SSA might have a flow exposed
here, if so, it should probably be fixed *too*.)
Note also that the cc0-equivalent of the above is simplified by
combine:
(insn 14 13 16 0 /home/hp/combined/combined/gcc/config/cris/arit.c:228 (set
(reg/v:SI 27 [ b.67 ])
(abs:SI (reg/v:SI 47 [ b ]))) 148 {abssi2} (insn_list:REG_DEP_TRUE 7
(nil))
(nil))
(insn 17 16 18 0 /home/hp/combined/combined/gcc/config/cris/arit.c:178 (set
(cc0)
(reg/v:SI 27 [ b.67 ])) 1 {tstsi} (insn_list:REG_DEP_TRUE 14 (nil))
(nil))
(jump_insn 18 17 20 0 /home/hp/combined/combined/gcc/config/cris/arit.c:178
(set (pc)
(if_then_else (ge (abs:SI (reg/v:SI 47 [ b ]))
(const_int 0 [0x0]))
(label_ref 26)
(pc))) 162 {bge} (nil)
(expr_list:REG_BR_PROB (const_int 7900 [0x1edc])
(nil)))
is simplified to:
(insn 14 13 16 0 /home/hp/combined/combined/gcc/config/cris/arit.c:228 (set
(reg/v:SI 27 [ b.67 ])
(abs:SI (reg/v:SI 47 [ b ]))) 148 {abssi2} (insn_list:REG_DEP_TRUE 7
(nil))
(nil))
(jump_insn 18 17 20 0 /home/hp/combined/combined/gcc/config/cris/arit.c:178
(set (pc)
(label_ref 26)) 162 {bge} (nil)
(expr_list:REG_BR_PROB (const_int 7900 [0x1edc])
(nil)))
(right after substitutions) and combine allows this, being a
three-for-two (with-lesser-cost) transformation.
The actual code should be simple; I just want to check that
there's consensus on the actual change before doing it.
Thoughts?
brgds, H-P
Re: GCC mailing list archive search omits results after May 2005
On Sat, 17 Dec 2005, Daniel Jacobowitz wrote: > On Sun, Dec 18, 2005 at 02:10:36AM +0100, Gerald Pfeifer wrote: > > I agree with that and plan to do so next week, once the server hosting > > my GCC trees is online again. > > Before you go ahead with that, please check with overseers@; they > (Frank in particular) have been setting up a new search engine for the > list archives all last week. That's one of the major reasons I kept it untouched. That, and it still worked. Besides that nothing important has happened since May. :-) (And Frank has already asked to stand by, so please wait a little longer.) brgds, H-P
Re: GCC mailing list archive search omits results after May 2005
On Tue, 13 Dec 2005, DJ Delorie wrote: > > Summary of the thread: it's known about and may never be fixed, but > > alternative searchable archives exist (gmane, nabble, probably > > others like marc and mail-archive too). > > Could we put in a google search box on the archive pages at least, to > stop confusing people? Technically feasible but politically sensitive. Considering that links on readings.html to sites that provide some software that's non-free-by-FSF-definition is forbidden, I'd like to know if that'd be allowed, and I'd want that answer straight from the GNU's mouth (so please don't start discussing it among just-subscribers-to-this-list and anyway don't CC me if you do). SC? brgds, H-P
Re: RFC: REG_LABEL not sufficient, cbranchM4 causes ambiguity
> Date: Mon, 12 Dec 2005 08:35:41 +0100 > From: Hans-Peter Nilsson <[EMAIL PROTECTED]> > ... the JUMP_LABEL field in a JUMP_P ... Almost-consistent typo: s/JUMP_LABEL/JUMP_TARGET/g to hopefully make a little bit more sense of it all. (Attempting a brain-dump before shuteyes always has some defects.) brgds, H-P
RFC: REG_LABEL not sufficient, cbranchM4 causes ambiguity
For once, the documentation seems to be most accurate; more
accurate than random comments in the code, of which some
contradicts other code:
@item REG_LABEL
This insn uses @var{op}, a @code{code_label} or a @code{note} of type
@code{NOTE_INSN_DELETED_LABEL}, but is not a
@code{jump_insn}, or it is a @code{jump_insn} that required the label to
be held in a register. The presence of this note allows jump
optimization to be aware that @var{op} is, in fact, being used, and flow
optimization to build an accurate flow graph.
However, for a cbranchsi4, the pattern can look like this:
(define_insn_and_split "cbranch4"
[(set (pc)
(if_then_else
(match_operator
0 "comparison_operator"
[(match_operand:BWDQ 1 "nonimmediate_operand" "")
(match_operand:BWDQ 2 "general_operand" "")])
(label_ref (match_operand 3 "" ""))
(pc)))]
...)
Causing for example in (from gfortran.dg/g77/pr9258.f and with
local CRIS-cc0-removal-changes):
(jump_insn 54 53 56 6 (set (pc)
(if_then_else (eq (reg/v/f:SI 25 [ m.1 ])
(label_ref:SI 0))
(label_ref 33)
(pc))) 1 {cbranchsi4} (nil)
(expr_list:REG_BR_PROB (const_int 1900 [0x76c])
(nil)))
Note *two* labels. One is a jump target, the other is an
operand. So, a JUMP_P can have multiple label references *some
of which are not jump targets*. This causes ambiguity with the
documented (and mostly real) use of REG_LABEL, and of course the
code assumes there are no non-jump-target REG_LABELs in JUMP_P:s.
I could of course "fix" this by disallowing REG_LABELs in
operand 2 in the pattern above, but that'd be like cheating,
giving in to a lame restriction in GCC and proving a
cbranchM4-representation to be lacking by definition with better
expressibility with cc0. Can't do that.
I propose (and will try to) solve this by splitting REG_LABELs
into two types, REG_LABEL_TARGET and REG_LABEL_OPERAND:
Only JUMP_P:s will have REG_LABEL_TARGET notes; those notes
marks its jump targets (perhaps can be only one). As a special
case, the JUMP_LABEL field in a JUMP_P is a short-cut and will
be handled as a first REG_LABEL_TARGET note. It is invalid to
have both JUMP_TARGET being NULL and REG_LABEL_TARGET notes in a
(JUMP_P) insn. A tablejump/casesi will have its JUMP_LABEL set
to the corresponding ADDR_VEC (there can be another
label-ref-target there, in case you think there'll only ever be
the JUMP_TARGET field and no REG_LABEL_TARGET notes).
A JUMP_P using a register for ordinary branches (like on sh64)
will have its JUMP_LABEL pointing to the label loaded in that
register (if it can be identified; it seems it usually can). To
make this work, REG_LABEL_TARGET notes (and the JUMP_LABEL) are
sticky; not removed before each jump pass if the JUMP_P no
longer refer to the label in its body.
Any insn can have REG_LABEL_OPERAND, which marks non-target use,
e.g. &&label operands and branch-target register loads in
non-jumps and the non-jump cbranchM4 (label-ref:SI 0) operand
above. (IIRC the 0 is actually due to the failure I saw.)
REG_LABEL_OPERANDs are regenerated for each jump pass.
A JUMP_P can have REG_LABEL_OPERANDs only for stuff in a
if_then_else condition; everything else is considered a
jump-target.
Or at least that's the definition I currently think (and hope)
will work.
Thoughts?
brgds, H-P
Re: htsearch broken?
On Thu, 8 Dec 2005, Paul Martinolich wrote: > I have noticed that when I search the mailing lists the earliest > messages > are from May 2005. I don't see anything before that. > > http://gcc.gnu.org/ml/gcc/ > > Search 'fortran' which shows the first message is: > > http://gcc.gnu.org/ml/gcc/2005-05/msg01645.html > > which was posted May 31, 2005. > > However, this message contains 'fortran' from just > earlier in the week: > > http://gcc.gnu.org/ml/gcc/2005-12/msg00126.html If you mean "latest" instead of "earliest", it's because the search engine has stopped indexing, permanently. No ETA; I'm not sure it'll be fixed at all. brgds, H-P
Re: testsuite issue
> Date: Wed, 07 Dec 2005 09:18:53 +0100 > From: "Jan Beulich" <[EMAIL PROTECTED]> Just for the record (in case someone else has the same thoughts) and because I'd already written most of the reply, I also replied to your first email. See last for your follow-up. > What has the alignment of type 'long long' to do with structure > packing? Only the obvious(?): if long long is usually padded in a structure, then marking it with attribute-packed has effect. IIUC for netware, you pack everything in structures *except* long long, which you pad to 32-bit alignment. Right? If not, then the warning emission machinery is wrong. > Structure packing is exactly to override the alignment of the > type. And in the given situation, alignment of 'long long' is at least > 32 (bits), whereas BITS_PER_UNIT is 8, and hence the attribute is really > not ignored (because the alignment gets overridden in order to pack the > field), hence the expectation of a warning here seems wrong. If not, can > you explain what it is that makes you expect a warning here? If "long long" is packed by default then a target default_packed *should* get the "is ignored" warning. On the other hand, if the warning is considered correct as emitted, you need to write something like a default_packed_except_long_long testsuite thingy and use that here. See default_packed bits. And later: >It should not only check TYPE_ALIGN (), but also consider current >structure packing in effect (and consequently, it should also be emitted >e.g. when #pragma pack(1) is in effect on a target that doesn't default >to packed structures). Agreed. I'd be happy to see this. brgds, H-P
Re: testsuite issue
> Date: Tue, 06 Dec 2005 18:02:51 +0100 > From: "Jan Beulich" <[EMAIL PROTECTED]> > >2005-12-01 Hans-Peter Nilsson <[EMAIL PROTECTED]> > > > > * gcc.dg/20041106-1.c, gcc.dg/20030321-1.c, gcc.dg/pr17112-1.c, > > gcc.dg/pr17112-1.c, g++.dg/other/packed1.C, > > g++.dg/other/crash-4.C, g++.dg/ext/packed8.C: Match "attribute > > ignored" warnings when "packing" is the same as the ABI layout. > > While most of these changes appear to be correct, I see a regression on > *-*-netware* (which by default uses packed structures) in > gcc.dg/20030321-1.c, and I believe the warning tested for cannot be > expected (since the code generating the warning tests > > TYPE_ALIGN (TREE_TYPE (*node)) <= BITS_PER_UNIT > > which cannot reasonably be expected to be true for 'long long'. Why not? If you don't get a warning for the attribute being ignored then, your target doesn't really pack structures; maybe we need to split default_packed into variants. > Can this part of the patch therefore be reverted? Uh, no. It works as intended and removing it would cause a regression. On the other hand, FWIW, I think the warning is generally bogus, but I've already mentioned that. brgds, H-P
Re: Torbjorn's ieeelib.c
On Mon, 28 Nov 2005, Mark Mitchell wrote: > So, we're considering doing what it takes to get ieeelib.c into GCC, or, > perhaps, borrowing some of its ideas for fp-bit.c. Very nice! Don't forget the few posts with bug-fixes over the years from someone or other. (Yes, actually posted here on a gcc-list, not to Tege.) brgds, H-P
Re: Performance regression testing?
On Tue, 29 Nov 2005, Mike Stump wrote: > > What field order looks better to you? I'm agnostic, except I'd > > like to keep one and the same field delimiter except for the > > result, and it's *slightly* easier to keep it as "," (as in the > > original csibe output). > > 4.1-sparc-r104567/my-perf-suite.sum > mainline-sparc-r102355/my-perf-suite.sum > > name_of_analysis_prog 4.1-sparc-r104567/my-perf-suite.sum mainline- > sparc-r102355/my-perf-suite.sum > > exactly like dejagnu. Here, there is no previous, there is only the > first argument to the analysis program, which, by definition names > the `previous' run. No, I mean the order of the fields of results for sub-tests *within* the result file, as you say you wanted some other. It seems we're talking past each other; I can't parse your reply as a reply, and I don't really understand how your name_of_analysis_prog runs would fit in the dejagnu framework. Hey, if you don't want to read the csibe.exp source, you'll have to wait until there's something I think may be worthy of a presentation rather than just a dump of w.i.p. :-) Oh well: in what I play with currently, baselines are input in multiple arbitrarily named files: each may contain one (part of) or more arbitrarily named (except for the delimiter) baselines. As baseline output, there will be one result file (TBD), containing for convenience as input to any other run, lines marked "previous" (for the current result) and "best" (an updated or created baseline named "best"). There are lots of lines of data in a baseline (exactly what is TBD, see csibe.exp for example). This file may be edited, split up in multiple files or whatever, serving as baseline input to a future run. If the raw CSiBE output data is needed for e.g. graphs, it's available too. Baseline data is just trivially derived from it. The dejagnu output is simply comparisons of each baseline to the current results (criterias TBD, example given in code). I'm not sure an external test-program should be used by the testsuite, if all it does is a "<=" comparison. Maybe as an option, default off? For post-testsuite-analysis, it's certainly simple enough to do what you mention. By the way, I don't want baseline data having .sum suffix since it doesn't have dejagnu PASS/FAIL contents. For one, the contrib/test_summary script wouldn't like it. brgds, H-P
Re: Performance regression testing?
On Tue, 29 Nov 2005, Mike Stump wrote: > On Nov 28, 2005, at 8:41 PM, Hans-Peter Nilsson wrote: > > runtime,-O1,zlib-1.1.4:minigzip,previous 0.32 > > Ah, ok, good. I'd eject the ,previous to the filename, and reorder > slightly, but, certainly that is trivial to do. Um, (typo?) not a filename, but a line from the file with raw results, alternatively the baseline input. The "previous" identifies the baseline. It's supposed to be sed-able as in e.g. "sed -e 's/,previous /,4.2-branch /' < csibe-results > /path/to/baseline/4.2-baseline". What field order looks better to you? I'm agnostic, except I'd like to keep one and the same field delimiter except for the result, and it's *slightly* easier to keep it as "," (as in the original csibe output). brgds, H-P
Re: Performance regression testing?
On Mon, 28 Nov 2005, Hans-Peter Nilsson wrote:
> I've attached the work-in-progress
If someone's missing the trivial sim-main-glue.c, here it is,
just for completeness. Not used for "native" testing.
brgds, H-P/* Glue for passing arguments to a simulator that can't pass
command-line arguments to the target, yet can do file I/O.
Copyright (c) 2005 Free Software Foundation, Inc.
This file is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
For a copy of the GNU General Public License, write the the
Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301, USA. */
#include
#include
#include
#include
const char _argfile[] = _ARGFILE;
/* We know we won't be passed more than this many/long parameters. */
static char args[1024];
static char *argv[32];
static char *envp[] = {"", NULL};
#undef main
extern int _main_wrapped (int, char *[], char *[]);
int
main (void)
{
char *argp;
FILE *argfile = fopen (_argfile, "r");
unsigned int i;
if (argfile == NULL)
abort ();
for (argp = args, i = 0;; i++)
{
/* Need room for NULL too. */
if (i >= sizeof (argv) / sizeof (argv[0]) - 1)
abort ();
if (fgets (argp, sizeof (args) - (argp - args), argfile) == NULL)
break;
argv[i] = argp;
argp += strlen (argp);
argp[-1] = 0;
}
argv[i] = NULL;
fclose (argfile);
exit (_main_wrapped (i, argv, envp));
}
Re: Performance regression testing?
On Mon, 28 Nov 2005, Mike Stump wrote: > On Nov 28, 2005, at 6:21 PM, Hans-Peter Nilsson wrote: > > I've attached the work-in-progress so I don't have to get into > > detail about what it does :-) except noting that you'll see in > > gcc.sum something like: > > > > PASS: csibe -O1 runtime zlib-1.1.4:minigzip not slower than best > > PASS: csibe -O1 runtime zlib-1.1.4:minigzip not more than .1% > > slower than best > > PASS: csibe -O1 runtime zlib-1.1.4:minigzip not more than 1% slower > > than best > > PASS: csibe -O1 runtime zlib-1.1.4:minigzip not more than 10% > > slower than best > > Hum, I'd prefer that the output format be: > > PERF: %f name of test You seem to be interpreting the gcc.sum format, thinking it's the raw "baseline" format. Which for the record is like: ... runtime,-O1,zlib-1.1.4:minigzip,previous 0.32 runtime,-O1,bzip2-1.0.2:bzip2.d,previous 0.32 runtime,-O1,bzip2-1.0.2:bzip2recover,previous 0.19 ... That was the "native" x86_64 output. Here's for cris-linux+cris-sim: .. runtime,-O1,zlib-1.1.4:minigzip,previous 1262089345.0 runtime,-O1,bzip2-1.0.2:bzip2.d,previous 945199067.0 runtime,-O1,bzip2-1.0.2:bzip2recover,previous 1555998754.0 Can't be compared with each other, if that's what you mean (how would that make sense?) but quite comparable to other baselines methinks. I refer to the implementation for further details. > then have an analysis package crunch that into the above format. ...and emitting PASS/FAIL after _comparing_ two or more arbitrary runs according to some criteria? Like above? ;-) > This way, one can _compare_ two arbitrary runs, which is a useful > property. The number can be thought of as time, such as the number > of clock cycles, but we only reeally care that it starts at zero, and > gets bigger as things go bad. You have to elaborate here. How does "biasing" the number of cycles to make it 0 help? Do you mean a deviation normalized between 0 and 1? How would you "reset" it? I think it'd just be confusing, and you'd have to expect and handle negative numbers. Better keep an explicit built-in baseline. Already implemented by looking in gcc.performance/csibe/baselines/$target_triplet and reading whatever file is there according to the format above. ...oops, a bug in the posted code; missing "$" on $subdir. And untested anyway. brgds, H-P
Re: m68k exception handling
On Mon, 28 Nov 2005, Jim Wilson wrote: > The DWARF2 unwind info method has little or no overhead until a > exception is thrown. This is the preferred method for most targets. In > this scheme, we read the DWARF2 unwind info from the executable when an > exception is throw, parse the unwind tables, and then follow the > directions encoded in the unwind tables until we reach a catch handler. > This approach has obvious problems if you are using a disk-less > OS-less target board. This approach also generally requires some C > library support, which is present in glibc, but may not be present in > newlib. You can find info on this approach here > http://gcc.gnu.org/ml/gcc/2004-03/msg01779.html No, everything necessary support-wise is in gcc libraries, no special stuff from newlib is needed. Make sure to use the right gcc-provided start-files, though: besides the usual crt0.o (spelling varies), crti.o and crtn.o; gcc adds crtbegin.o and crtend.o. (You don't really read exception tables "manually" from the executable at exception time; it's linked in. You don't do that for the normal bunch of "hosted" systems either FWIW. It may be different for IA64.) brgds, H-P
Re: Overwrite a file with "svn update"?
On Sun, 20 Nov 2005, Andreas Schwab wrote: > Hans-Peter Nilsson <[EMAIL PROTECTED]> writes: > > On Sat, 19 Nov 2005, Steve Kargl wrote: > >> On Sat, Nov 19, 2005 at 11:29:36AM -0800, Jim Blandy wrote: > >> I believe if the file is in a cvs repository and the copy > >> in your local tree was not obtained via a checkout, cvs > >> will replace the local file with whatever is in the repository. > > > > No, it'll continue to update the rest of the tree but emit an > > error (i.e. not bail out immediately like svn). IIRC. > > If the local file is identical to the check-out version then there is no > error and the local file becomes a version-controlled file. I've never seen this, always the collision message, so I guess it's version-dependent. brgds, H-P
Re: Overwrite a file with "svn update"?
On Sat, 19 Nov 2005, Steve Kargl wrote: > On Sat, Nov 19, 2005 at 11:29:36AM -0800, Jim Blandy wrote: > I believe if the file is in a cvs repository and the copy > in your local tree was not obtained via a checkout, cvs > will replace the local file with whatever is in the repository. No, it'll continue to update the rest of the tree but emit an error (i.e. not bail out immediately like svn). IIRC. > > However, if I'm understanding it right, here Subversion is hesitating > > to replace a file with a file of the same name whose contents are the > > same. Is that correct? > > Yes. I see this regularly too, like when I write a test-case in another tree than where I'll commit it and forget to remove it before the next update of the first tree. I like Jim Blandy's suggestion that svn could just emit some informational message if the contents is the same as the some revision (first or HEAD presumably) and just go on. brgds, H-P
Re: m68k does not build on head
> From: Paul Brook <[EMAIL PROTECTED]>
> Date: Thu, 17 Nov 2005 15:12:50 +
> > ../../../gcc-head-test/libiberty/regex.c:7699 (set (reg:SI 2 %d2)
> >
> >(sign_extend:SI (reg:HI 1 %d1 [59]))) 65 {*68k_extendhisi2} (nil)
> >(nil))
> > ../../../gcc-head-test/libiberty/regex.c:7724: internal
> > compiler error: in reload_cse_simplify_operands, at postreload.c:393
>
> I'm also seeing this on m68-elf.
>
> It appears to have been caused by the following patch (r106804)
Or perhaps the patch that tightened operand checks for "g".
Please open a PR with preprocessed source attached and assign it
to me.
brgds, H-P
Re: UNITS vs. BYTES
On Fri, 11 Nov 2005, Adrian Prantl wrote: > Hello everybody, > > I am currently working on creating a new gcc backend for a word-addressable > machine with 24-Bit general purpose registers. If the smallest unit you can address, the one between address N and N+1, is a "word" then the unit must be a "word". (You don't say the size of this "word" but from the context it seems the size of your registers, 24 bits.) Then you have to adjust (generalize) the gcc sources which has bitrotted slightly to assume a unit is an 8-bit-byte, i.e. likely the inconsistency you see. It'd be best if/when you submit your GCC port to include newlib, simulator and binutils ports (so everyone can regression-test without hardware using only FSF sources) to reduce the risk of future GCC bitrot in this area. Thanks. brgds, H-P
Re: r106743 - in /trunk/gcc: ChangeLog Makefile.in ...
On Thu, 10 Nov 2005 [EMAIL PROTECTED] wrote: > Author: dberlin > Date: Thu Nov 10 17:23:49 2005 > New Revision: 106743 > 2005-11-10 Daniel Berlin <[EMAIL PROTECTED]> > (heapvar_lookup): New function. /home/hp/combined/combined/gcc/tree-ssa-structalias.c: In function `heapvar_lookup': /home/hp/combined/combined/gcc/tree-ssa-structalias.c:320: error: `from' undeclared (first use in this function) /home/hp/combined/combined/gcc/tree-ssa-structalias.c:320: error: (Each undeclared identifier is reported only once /home/hp/combined/combined/gcc/tree-ssa-structalias.c:320: error: for each function it appears in.) /home/hp/combined/combined/gcc/tree-ssa-structalias.c:317: warning: unused parameter `stmt' make[4]: *** [tree-ssa-structalias.o] Error 1 I'll make the obvious s/stmt/from/ in that function if it trivially fixes the build (and nobody else got to it). But as it must've been untested, it seems likely there are other bugs in that commit. brgds, H-P
Re: [RFC] What should be the semantics of a zero-bit bit-field with pragma pack?
On Mon, 7 Nov 2005, Steven Bosscher wrote: > 2) when we see :0 align to the next unit, which seems to be the >behavior of GCC pre-3.4. If by "unit" you mean "size of type for the :0 field" for targets with PCC_BITFIELD_TYPE_MATTERS==1, and "byte" for non-PCC_BITFIELD_TYPE_MATTERS targets, fine with me. Actually, only the latter is of interest to me at present. :-) (Else that'd imply a change of the ABI for CRIS which is "packed by default" so :0 causes padding to the next byte.) brgds, H-P
Re: Old machine cluster for GCC compile/testing
On Tue, 9 Aug 2005, Sebastian Pop wrote: > Laurent GUERBY wrote: > > > > So I'm asking for project proposals, that is to say people that think > > that their volunteer time to work on these old machine (scripts, > > compiling, ... under the limit of minimal external bandwidth use) is of > > some significant benefit to some free software project. > I'm proposing to automate gcc's bootstrap & regtest: for each mail > sent to [EMAIL PROTECTED], if 'From' is in gcc-developpers and 'body' > contains a patch against some branch (ie. if it fails to apply to a > branch, just drop it and warn the user), enqueue it for validation. And I'd like to add to that proposal, that the target to test should be controllable (default "native), to simplify cross-testing. (Not saying whether it should be possible to specify multiple targets.) Perhaps simplest done by using geoffk's script contrib/regression/btest-gcc.sh, which makes this bit mostly trivial. brgds, H-P
CC_REG: "Ian's cc0 replacement machinery", request for stage 2 conceptual approval
After synchronizing with Ian Lance Taylor on IRC, I'm in the process of implementing the cc0 replacement machinery he described here and found at http://gcc.gnu.org/wiki/general%20backend%20cleanup> after "Here is a possible approach in which macros are used in the MD file readers to avoid the pattern explosion". I understood noone else is working on this. The approach is named CC_REG for brief (it's gated on a define_constant by that name). I haven't yet bumped into anything that need fundamental changes to the presented approach. The most important reason why I do this, is that I need the CRIS port to move away from the classic cc0-representation in order to include a subport (CRIS v32) which for performance needs scheduling for a modest single five-stage pipeline. IIUC patches have been presented for the DFA scheduler to support the cc0 machinery, but the patches were rejected as support being unwanted for cc0 machinery. The cc0 machinery has always been intrusive in the middle-end which is the main reason why it's no longer the preferred method for describing condition codes. The CC_REG approach seemed like a better approach than the brute-force approach used with the i386 port, mostly regarding port maintenance and pattern explosion in the .md file. What worries me most is that I'll not meet the Stage 1 end of the 25:th. This CC_REG machinery patches would arguably be affecting many files and as such be stage 1 material, but doesn't at all functionally affect any primary platform (all being non-cc0) or ports that still use the cc0 approach. The presented approach is recent and wasn't known until well into stage 1, so it couldn't be one of the "official" stage 1 projects. Still, I hope for an exception, assuming a patch is ready for review in about two weeks for inclusion in HEAD, to-be 4.1. brgds, H-P
Re: Obsoleting c4x last minute for 4.0
On Sat, 23 Apr 2005, Hans-Peter Nilsson wrote: > On Wed, 6 Apr 2005, Joseph S. Myers wrote: > > (If test results for a port are so bad that > > though sent to gcc-testresults they exceed the message size limit, and > > this remains the case for a prolonged period such as ever since 4.0 > > branched, that also indicates lack of active maintenance.) > > No, it could just as well be a problem with the library, as is > the case for libgfortran; tests still run even though it's > disabled for mmix-knuth-mmixware. (There's a PR about it > somewhere, IIRC.) The *fortran* tests still run (and the front-end is built) although libgfortran is disabled. It seems I was mistaken about there being a PR. Hum. For cris-elf, the fortran tests just FAIL all over due to missing references to ftruncate, dup and access (not provided by newlib but apparently assumed by libgfortran). Last time I checked, there was very little maintaier interest in getting cross-building and cross-testing to work for fortran. I myself have no interest in it other than as a testbed. brgds, H-P
Re: Obsoleting c4x last minute for 4.0
On Wed, 6 Apr 2005, Joseph S. Myers wrote: > (If test results for a port are so bad that > though sent to gcc-testresults they exceed the message size limit, and > this remains the case for a prolonged period such as ever since 4.0 > branched, that also indicates lack of active maintenance.) No, it could just as well be a problem with the library, as is the case for libgfortran; tests still run even though it's disabled for mmix-knuth-mmixware. (There's a PR about it somewhere, IIRC.) Having said that, I do *not* consider it a requirement or equivalent for port maintenance to send test-results to gcc-testresults at any specific time or interval. For simulators with free components, people can run the tests themselves if they're interested. brgds, H-P
Re: A plan for eliminating cc0
> From: Ian Lance Taylor > Date: 29 Mar 2005 23:05:11 -0500 > Hans-Peter Nilsson <[EMAIL PROTECTED]> writes: > What am I missing? If anything, to post an updated proposal spelling out the bits below! (I.e. nothing as long as there is always a matching automatically generated insn; one with an added (set (reg CC_REG) (unspec ...)) for every insn where NOTICE_UPDATE_CC can presently indicate a "redundant" cc0 setter.) > The gen* files will need to duplicate each > instruction with the clobbercc (or cc0) attribute, You know it, but for the record (needs to be spelled out): every insn "has the attribute". It's a matter of which can have it set to a value that indicates that cc0 can be set to something not explicit in the RTL, i.e. for "clobbercc" it'd be "yes", for "cc0" any attribute value but "explicit" (cc0 users that aren't setters) and perhaps a separate value "manual", where no automatic handling/expansion is applied. > producing one > version which clobbers the cc and one version which sets it to an > unspec. When the new optimization pass deletes an instruction, it > will convert the previous clobbercc instruction to the variant which > sets cc to an unspec. Note that the maintainer does not have to write > an additional patterns to make this work. The information in the last sentence is what I was missing. Good! > Given the above, I don't think there will be pattern explosion, at > least not manually written pattern explosion. FWIW, only manual pattern explosion matters to me as a target maintainer (generic regressions due to explosion can be dealt with target-independently). brgds, H-P
Re: A plan for eliminating cc0
I'm behind on reading mailing lists and only "skipped ahead" for this thread. (I may have missed some related follow-ups.) > From: Ian Lance Taylor > Date: 24 Mar 2005 11:44:52 -0500 > 1) Modify the programs which read the .md file to look for an >attribute named clobbercc. If such an attribute exists, then for >any instruction pattern which defines clobbercc as "yes" (or >"true", or whatever), automatically add "(clobber (reg:CC CC_REG))" >to the instruction. I had a similar but not substantiated plan, where I named the attribute "cc0" (that name is not used by backends; values matching yours would be "clobber" and "unmodified" or "none"). The "cc0" name seems better and more intuitive than "clobbercc" which implies a binary value. It'd be easier language-wise to add handling for values like "set_dest" (cc0 set according to destination); the attribute name wouldn't then need tweaking to make sense later on. Similarly but perhaps more importantly for the cc_status.flags handling; translating other cc0 attribute values to machine-generated CCmodes. Working on a plan I got stuck on a couple of things, most importantly the cost/benefit below, IMHO a show-stopper. Another point was how to get a usable register number for cc0 and associated. Leaving it to the target to define makes sense but it also means there's some work to adjust register classes etc; an area where bugs get nasty (i.e. hard to determine the cause from the effect). I wish there was a gap between the hard registers and the first pseudo register. > 2) Modify the programs which read the .md file to look for >instructions which set cc0 and instructions which use cc0. If >CC_REG is defined for the backend, then for each such instruction: ... Makes sense, as long as *everything* in (2) happens in the gen* programs. > 4) For each target which uses cc0: ... >4b) For insn patterns for which some alternatives clobber CC and >some do not, split the instruction after reload into one >variant which clobbers the CC and one variant which does not. >Or just write different patterns which are only recognized >after reload. An IMHO show-stopping problem with 4b is that writing all matching variants is lots of work; the conversion cost in total would not be significantly less work for a target than "brute force" conversion (like the one done in the i386 port) and you'd get pattern explosion in the .md. At least if you want to avoid a performance regression. > 5) Write a new optimization pass enabled on targets which define >NOTICE_UPDATE_CC. I think this pass would be run just before >machine dependent reorg, although perhaps there is a better place >for it. Walk through the instructions, calling NOTICE_UPDATE_CC on >each one. When we find an instruction which sets CC_REG, check the >source of the set with the current CC status, just as >final_scan_insn does now. If the current CC status is the same, >delete the instruction which sets CC_REG. (Needs to be augmented with:) ... but change the noticed-insn (into a parallel if not already one) that also sets CC_REG, and check that the resulting parallel insn is recognized before going ahead with removing the original cc0-setter. (If you don't do this step, you'll get in trouble with missing sets of CC_REG for flow info, and unrecognized-insn ICEs.) If the resulting insn is unrecognized && ifdef ENABLE_CHECKING, emit a warning, so the target maintainer notices the opportunity for optimization (i.e. which was there with the "old" NOTICE_UPDATE_CC handling). > At this point, the generated code quality should be approximately the > same as when the target used cc0. Not without pattern explosion for the additional cc0-setter combinations. Also, extra tweaks would be needed to make up for the missing handling of e.g. cc_status.flags. I suggest that (it's ok to admit that) the approach you suggest is likely to get decreased performance (without massive target tweaking), but is a suggested easy-way-out for target maintainers and absence of interested target maintainers. > I want to stress that that this approach is intended to permit > reasonably simple elimination of cc0 for all targets. It does not > preclude any particular target from using a different approach. Yes, this is good, a sign of of a sane approach. :-) > I don't think that a more accurate representation will help very much > without a lot more work, because the optimizers won't really be able > to use the better representation until after reload, and we don't do > very much optimization after reload. Specifically, I don't think a > better representation will improve very much on the proposed > NOTICE_UPDATE_CC optimization pass. But nothing in what I am > suggesting precludes following this path. Except for the clobbercc *name*. :-) But I think this suggestion and similar ones along this line is doing too much for too little gain. To
Re: Questions about trampolines
On Sun, 13 Mar 2005, Øyvind Harboe wrote: > Trampolines are strange things... :-) > - AFAICT, the cris target is saving the value of the > static chain register in the trampoline. How can that work > with recursive functions? What's wrong with that? Do I miss something fundamental? > Does the cris target PASS or FAIL > gcc.dg/trampoline-1.c? Why not try it yourself? All the tools are present. ;-) But I'll spoil the fun: no, it calls abort. I haven't looked into it. brgds, H-P
Newlib _ctype_ alias kludge now invalid due to PR middle-end/15700 fix.
On cris-axis-elf, with LAST_UPDATED "Wed Mar 16 14:54:19 UTC 2005":
make[9]: Entering directory
`/home/hp/combined/cris-sim/cris-elf/v10/newlib/libc/ctype'
/home/hp/combined/cris-sim/./gcc/xgcc -B/home/hp/combined/cris-sim/./gcc/
-nostdinc -B/home/hp/combined/cris-sim/cris-elf/v10/new\
lib/ -isystem /home/hp/combined/cris-sim/cris-elf/v10/newlib/targ-include
-isystem /home/hp/combined/combined/newlib/libc/include\
-B/usr/local/cris-elf/bin/ -B/usr/local/cris-elf/lib/ -isystem
/usr/local/cris-elf/include -isystem /usr/local/cris-elf/sys-incl\
ude -L/home/hp/combined/cris-sim/./ld -march=v10 -mbest-lib-options
-DPACKAGE=\"newlib\" -DVERSION=\"1.13.0\" -I. -I/home/hp/co\
mbined/combined/newlib/libc/ctype -O2 -DHAVE_RENAME -DHAVE_GETTIMEOFDAY
-D_USE_WRITE -fno-builtin -O2 -g -O2 -march=v10 -m\
best-lib-options -c /home/hp/combined/combined/newlib/libc/ctype/ctype_.c
/home/hp/combined/combined/newlib/libc/ctype/ctype_.c:91: warning: '_ctype_'
aliased to undefined symbol '_ctype_b+127'
(compilation continues)
But with LAST_UPDATED "Wed Mar 16 21:10:54 UTC 2005":
make[9]: Entering directory
`/home/hp/combined/cris-sim/cris-elf/v10/newlib/libc/ctype'
/home/hp/combined/cris-sim/./gcc/xgcc -B/home/hp/combined/cris-sim/./gcc/
-nostdinc -B/home/hp/combined/cris-sim/cris-elf/v10/new\
lib/ -isystem /home/hp/combined/cris-sim/cris-elf/v10/newlib/targ-include
-isystem /home/hp/combined/combined/newlib/libc/include\
-B/usr/local/cris-elf/bin/ -B/usr/local/cris-elf/lib/ -isystem
/usr/local/cris-elf/include -isystem /usr/local/cris-elf/sys-incl\
ude -L/home/hp/combined/cris-sim/./ld -march=v10 -mbest-lib-options
-DPACKAGE=\"newlib\" -DVERSION=\"1.13.0\" -I. -I/home/hp/co\
mbined/combined/newlib/libc/ctype -O2 -DHAVE_RENAME -DHAVE_GETTIMEOFDAY
-D_USE_WRITE -fno-builtin -O2 -g -O2 -march=v10 -m\
best-lib-options -c /home/hp/combined/combined/newlib/libc/ctype/ctype_.c
/home/hp/combined/combined/newlib/libc/ctype/ctype_.c:91: error: '_ctype_'
aliased to undefined symbol '_ctype_b+127'
make[9]: *** [ctype_.o] Error 1
Apparently due to:
+ 2005-03-16 Richard Henderson <[EMAIL PROTECTED]>
+
+ PR middle-end/15700
+ * varasm.c (struct alias_pair): Rename from struct output_def_pair.
+ (alias_pairs): Rename from output_defs.
+ (find_decl_and_mark_needed): Split out from assemble_alias.
+ (do_assemble_alias): New.
+ (assemble_output_def): Remove.
+ (finish_aliases_1, finish_aliases_2): New.
+ (process_pending_assemble_output_defs): Remove.
+ (assemble_alias): Defer aliases for which we don't yet have a
+ non-external decl for the target symbol.
+ * passes.c (rest_of_decl_compilation): Register variables with cgraph.
+ * cgraphunit.c (cgraph_finalize_compilation_unit): Use finish_aliases_1.
+ * toplev.c (compile_file): Use finish_aliases_2 instead of
+ process_pending_assemble_output_defs.
+ * tree.h (finish_aliases_1, finish_aliases_2): Declare.
+ (process_pending_assemble_output_defs): Remove.
So, the previously-questionable newlib alias-to-offset-in-table
kludge is finally judged invalid. This is a heads-up for newlib
users. IMHO it's not a GCC bug, though there's surely going to
be some commotion. Maybe a NEWS item is called for, I dunno.
I intend to commit the obvious fix for cris-axis-elf newlib
shortly, but I think all newlib ports that do not already set
the slightly less optimal but valid construct available by
setting 'newlib_cflags="${newlib_cflags} -DCOMPACT_CTYPE"' in
configure.host (see the mmix-* entry).
brgds, H-P
Re: request for timings - makedepend
On Mon, 7 Mar 2005, Zack Weinberg wrote: > I would take this approach if there were a sensible way to deal with > the generated sources. (Late in the game here, but I see no solution in later posts in this thread.) All #includes that can appear are in the gen* files IIUC. Can those be marked up, then grepped out when making dependencies? brgds, H-P
Re: Feature request: Globalize symbol
> From: James E Wilson <[EMAIL PROTECTED]> > Date: Fri, 11 Mar 2005 17:52:03 -0800 > On Fri, 2005-03-11 at 08:12, Hans-Peter Nilsson wrote: > > I don't really understand what you mean: if a thing is called > > "foo" in the source, then -fglobalize-symbol=foo would work. > > My main concern is that we have a long history of adding flawed features > that have to be later removed. That describes some GCC extensions rather than features invoked by explicit options, IIRC. > So I want you to try to think about > anything that might possibly go wrong now instead of just assuming that > it will obviously work. In general, those are my concerns too. But we're not at the stage when precise definition is called for: I wanted to get initial reaction. That was negative. Further discussion is academic. > You are proposing a new kind of option, one > that first translates symbolnames to variable names, and then changes > their linkage, so you need to carefully define exactly how this works in > all cases, and how it interacts with all existing gcc features. The proposal is an instrumentation feature that is explicitly invoked, not a GCC extension that can appear anywhere in the source. For such a feature, I think it would (for example) be enough to define a domain where the feature works, and declare everything else a (possibly undetected) error. > The original poster mentioned an interaction with .hidden, so you need > to define how the feature of removing static interacts with visibility > attributes. Yes, I asked Hugo to describe interaction of the feature with the visibility attribute. Unfortunately that was not defined in the necessarily explicit terms in the proposal. Fortunately, no intricate rules are needed: visibility attributes do not appear on things declared static. (They are ignored with a warning; best would be to force the "default" visibility when the option is in effect, with or without the current warning.) > There may also be other issues that need to be dealt with. It would be > useful to browse the C standard and the list of gcc extensions to look > for possible issues that might need to be dealt with. It may also be > useful to look at how gcc internals handle static and look for potential > problems. Good implementation advice. > I am not opposed to the feature in principle. Thanks. This is the level of answer I actually was looking for. > I just think that you > aren't being vigorous enough in defining it. I am not defining it. You're too vigorous trying to make me do that at this time. My intention was to correct misunderstandings about what the feature was *intended* to do. This in order to get informed feedback whether this feature would be acceptable for FSF GCC. It seems in doing that, I have been dragged into discussion about a formal precise definition of the feature. That's premature. I would of course look into neighboring areas and options if I would implement this. Right now, I think that will not happen. I do know of the getting-detailed-definitions-of-GCC-extensions problem; please assume I have the same basic concerns as anyone here. Really no need to reiterate on that. (Any/All: If you now want to discuss whether a full implementation, specification and documentation *must* be present in order to get an *initial* reaction on a GCC feature, please change the subject. Please.) > I'd like to see a formal > specification of what the option does, both in how the symbolname to > variable mapping works, and in how the static removal works. In due time. Having said all that, the intended main effect would be the equivalent of "#define static" (or "-Dstatic=") in C when there are only file-scope statics (i.e. not affecting function-level statics). That's all at the moment. Everything else is corner cases and side-effects; details to be defined. > Richard however does appear to be objecting in principle, which is > another matter. Alas. Still, that answer was at the "right" level for me at this time. I have to discuss this with Hugo when he's back from vacation. brgds, H-P
Re: Feature request: Globalize symbol
> From: James E Wilson <[EMAIL PROTECTED]> > Date: Thu, 10 Mar 2005 21:51:12 -0800 > On Thu, 2005-03-10 at 20:14, Hans-Peter Nilsson wrote: > > That question isn't applicable or maybe I should say "by > > identity mapping". To wit, SYMNAME refers to whatever has > > "static" in front of it *in the source code*, but for which you > > want it removed, i.e. globalized (speaking in C terms). > > I think you fail to appreciate the complexity of a compiler symbol > table. Perhaps, perhaps not. Right now, my interest is in defining the functionality seen by the user. > Particularly when GNU extensions are involved, and when > languages like C++ are involved. If you restrict yourself to ISO C, > then yes it will probably work in all cases. Otherwise, no, it won't. I don't really understand what you mean: if a thing is called "foo" in the source, then -fglobalize-symbol=foo would work. Naturally, the usability is restricted to the cases where the language has the distinction of a "local foo" and a "global foo", similar to C's static and non-static file-scope functions and variables. Another prerequisite is that other functionality (-fPIC) exists to override the symbol in another translation unit. Globalizing a C++ namespace, class or class member wouldn't work, for example. > You really should look at the #pragma redefine_extname and extern_prefix > documentation, FWIW I did look at that documentation. I did not see any particular applicable problems there. It seems you insist on this being a symbol-mapping modification, rather than a declaration modification. (If the "global" declaration or definition would be in error, well then emit an error. I don't see redefine_extname or extern_prefix interfering or being otherwise related - they don't apply to definitions local in the source!) > which lists a number of cases where this "by identify > mapping" concept doesn't work. I didn't see any that would apply to -fglobalize-symbol*, because the pragmas you mention apply only to external symbols (those declared in the source as external). An applicable example from the cases you see would help. Maybe this focus on the *generated symbols* is because I said "not a source-level modification" together with mentioning --wrap. I did mean "not a source-*code* modification". Sorry. Maybe the proposed option name had a part too. :-) All that just said for the record, because unfortunately due to yours and rth's negative reception of the proposal, I conclude that this feature does not currently have any chance of being accepted for FSF GCC. Oh, well. brgds, H-P
Re: Feature request: Globalize symbol
> From: James E Wilson <[EMAIL PROTECTED]> > Date: Thu, 10 Mar 2005 19:34:01 -0800 > On Thu, 2005-03-10 at 17:48, Hans-Peter Nilsson wrote: > > Of course! The simple (and best) way out is to define what > > happens in all those situations as the equivalent of removing > > "static" for such an identifier in file scope > > I think you missed my point. The proposed -fglobalize-symbol=SYMNAME > option assumes that it is obvious what a variable's symbol name is. I'm referring to the name *that appears in the source code*. Not the symbol at the assembly level. > So when an option mentions a symbol name, exactly how do we find the > variable that matches that symbol name? That question isn't applicable or maybe I should say "by identity mapping". To wit, SYMNAME refers to whatever has "static" in front of it *in the source code*, but for which you want it removed, i.e. globalized (speaking in C terms). > Also, there is still the question of how this gets used for > instrumentation. For instance, you mentioned that you want to use > linker wrapping, but the linker wrapping would have to use the assembler > name of the symbol which can be arbitrarily different from the source > level variable name. So you need two possibly very different symbol > names for the -fglobalize-symbol and --wrap options, and there is no > foolproof way for the external unit tester to know the mapping between > the -fglobalize-symbol DECL_NAME and the --wrap options > DECL_ASSEMBLER_NAME. Of course, this won't be a problem in the common > case for ordinary C global variables, but it does mean that the unit > tester won't be able to handle all cases. Hence this may not be the > best approach to solve the general problem of unit testing. No, the "hence" doesn't necessary follow: your argument assumes that --wrap is the only way to use -fglobalize-symbol=SYMNAME. It is true that --wrap isn't generally usable for anything but C (or simple source-to-assembly-mapping) for the reasons you mention but that's nothing new. I mentioned --wrap just as *one* way of modifying SYMNAME later on (so please don't get stuck on it): -fglobalize-symbol=SYM would still be usable without it, for example compile the code with -fpic, make a DSO out of it and override SYMNAME in another DSO or the executable. No need to know mangling there. If there was use of redefine_extname or asm to define SYMNAME at the assembly-level name, it better be used in the overriding code as well. brgds, H-P
Re: Feature request: Globalize symbol
> Date: Thu, 10 Mar 2005 17:36:37 -0800 > On Thu, 2005-03-10 at 16:55, Hans-Peter Nilsson wrote: > > But that requires source-level instrumentation. > > Isn't a compiler option -fglobalize-symbol also a form of source-level > instrumentation? Either way, you need the source, and you get different > code emitted. This isn't a source-level modification, by definition. > If you are interested in implementing this, you should consider how this > will interact with other compiler features such as __asm__, attribute > ((alias)), and C++/Java name mangling. Of course! The simple (and best) way out is to define what happens in all those situations as the equivalent of removing "static" for such an identifier in file scope (including emitting errors where that results in invalid/erroneous/your-name-for-wrong code). Errors to be emitted when "conflicts" occur. (If there is no matching identifier SYMNAME in file scope for -fglobalize-symbol=SYMNAME, I think it's best if nothing happens.) > Also, I think the IPA support > will rename variables behind your back to try to avoid conflicts, e.g. > if you try to compile two source files into one object file. No, I don't think so. What will happen is the same as when there would (wrongly) be two globals by the same name: an error would be emitted. No surprises. brgds, H-P
Re: Feature request: Globalize symbol
> Date: Thu, 10 Mar 2005 14:41:23 -0800 > From: James E Wilson <[EMAIL PROTECTED]> > Fredrik Hugosson wrote: > > My proposal is the following new options: > > -fglobalize-symbol=SYMBOLNAME > > -fglobalize-symbols=FILENAME > > -fglobalize-all-symbols > > It is unlikely someone will volunteer to implement a feature that only > you need. On the other hand, this is a future that seems likely to be of use to others, and it's likely that I'll help implement it, if the usability and other details are agreed upon. > Globalizing a symbol in a shared library is potentially unsafe, and that > may resulting in linker conflicts, or it may result in a shared library > variable being overriden by a variable in another module causing silent > changes in behaviour. I think you misunderstood. The suggested feature is for *non-source-intrusive instrumentation* only. The goal is to make static-declared functions and variables in file scope to be global, not static, so they *can* be overridden elsewhere and/or renamed through the GNU linker "--wrap" feature. Perhaps it is better described that -fglobalize-all-symbols would be equivalent to "#define static" when there are no function-scope statics. I'm told there are no known way to accomplish this by other means. Of course the user of that option must know that no (unintended) symbol conflicts occur. > Another way to attack this problem would be to add accessor functions to > the shared libraries. But that requires source-level instrumentation. brgds, H-P
Re: PATCH RFA: Use years for ChangeLog names
On Sun, 6 Mar 2005, Ian Lance Taylor wrote: > Going forward, in early July of each year ChangeLog would be moved > into ChangeLog-. Then in early January, ChangeLog would be moved > to the front of ChangeLog-. More natural would be to split off ChangeLog entries for the previous year early January. > When I proposed this a couple of months ago, Hans-Peter objected: > http://gcc.gnu.org/ml/gcc/2005-01/msg00640.html > I honestly didn't understand the objection. Hans-Peter, let me know > if you want to try again to explain it. Nope. If you feel strongly enough to rename and fiddle with the old files, go ahead. I still feel the change is unnecessary (and as such should only apply to new splits) but I don't feel strongly about it. brgds, H-P
Re: matching constraints in asm operands question
On Tue, 1 Mar 2005, Peter Barada wrote:
>
> I'm trying to improve atomic operations for ColdFir ein a 2.4 kernel, and
> I tried the following following the current online manual at:
> http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Extended-Asm.html#Extended-Asm
>
> static __inline__ void atomic_inc(atomic_t *v)
> {
> __asm__ __volatile__("addql #1,%0" : "=m" (*v) : "0" (*v));
> }
>
> but that genreates *lots* of warning messages about "matching
> contstaint doesn't allow a register".
Sounds like a bug to me.
brgds, H-P
RE: Plan for cleaning up the "Addressing Modes" macros
On Mon, 28 Feb 2005, Dave Korn wrote:
> Hmmm, actually, I would say that moving these macro definitions into the
> cpu.c files is a fairly mechanical and trivial transformation. Given:
WRONG!
> ${CPU}.h:
> #define GO_IF_LEGITIMATE_ADDRESS(MODE,X,ADDR) \
> if ( some very hairy conditional depending on REG_OK_STRICT ) \
> goto ADDR;
>
> you just redefine it as
>
> ${CPU}.h
> #define GO_IF_LEGITIMATE_ADDRESS(MODE,X,ADDR) \
> if (${CPU}_go_if_legitimate_address ((MODE), (X), (REG_OK_STRICT)) \
> goto ADDR;
>
> ${CPU}.c
> int ${CPU}_go_if_legitimate_address (enum machine_mode mode, rtx x, int
> reg_ok_strict)
> {
> return ( ... same conditional s/REG_OK_STRICT/reg_ok_strict/g );
> }
And then, much later on, perhaps not even from the GCC
test-suite, you find that a helper macro of a helper macro used
in the GO_IF_LEGITIMATE_ADDRESS (said helper macro still being
defined in cpu.h) is dependent on REG_OK_STRICT.
As a port mauthor/maintainer, you do this *once*. Then you stay
alert about moving REG_OK_STRICT-dependent things into cpu.c.
brgds, H-P
Re: [RFA:] change back name of initial rtl dump suffix to ".rtl".
> Date: Mon, 21 Feb 2005 11:19:59 +0100 > From: Paolo Bonzini <[EMAIL PROTECTED]> > > Do you know of a reason why that isn't on by default? > > Because -fdump-rtl-expand-detailed includes *two* copies of the RTL: one > lacks the prologue and epilogue but is interleaved with trees, the other > is the standard -fdump-rtl-expand dump. That's not really a compelling reason to make it optional; we're talking dumps that are supposed to be maximally informational! (But maybe a reason to make it just one dump, the interleaved one.) brgds, H-P
Re: Stack Checking implementation problems
On Wed, 9 Feb 2005, James E Wilson wrote: > A workaround would be to add a special unspec RTL pattern that emits the > bgeu/break/label. Then you would no longer have control-flow inside the > prologue. You can use the gas local label feature to avoid needing to > create a label rtx. Or (for the record) instead of assuming gas, use the "%=" gcc asm format sequence that emits a unique number for this insn, which together with proper local label syntax can be used to form a label. See final.c:1.344:3091. brgds, H-P
