Re: GCC 4.2.1 : bootstrap fails at stage 2. compiler produces wrong binary for wrong processor
That isn't what I see here. The output binary was definately for a v8plus processor. That would be a UltraSparc 1 at the least. There is no real V8+ architecture, V8+ is an augmented 32-bit ABI for the V9 architecture, the native ABI of the V9 architecture being the 64-bit ABI. The mapping between -mcpu settings and 32-bit ABI levels is as follows: -mcpu 32-bit ABI v7 v7 v8 v8 v9 v8plus ultrasparc v8plusa ultrasparc3v8plusb -- Eric Botcazou
Re: Refactoring tool
> Having spent some time looking at the code for gcc it seems reasonably > easy(with some suggestions) to traverse the tree generated and > write the relevant information to a file. Any suggestions or pointers to > related work would be much appreciated. For C and C++, it might be easier to use a stand alone parser. Depending on what you want, these might be sufficient: http://llvm.org/cfe/ http://www.cs.berkeley.edu/~smcpeak/elkhound/sources/elsa/ > Patrick Cheers, -- Rafael Avila de Espindola Google Ireland Ltd. Gordon House Barrow Street Dublin 4 Ireland Registered in Dublin, Ireland Registration Number: 368047
Re: How to make use of instruction scheduling to improve performance?
"吴曦" <[EMAIL PROTECTED]> writes: > Sorry, I didn't find that pass in gcc 4.1.1. This pass is added in the > newest gcc? I see from your later message that you found it. > > allocation. It means that the prologue and epilogue instructions are > ~~ > As you have indicated, this pass happens after register allocation, I > want to allocate register rather than dedicating register to do the > instrumentation calculation, are there any hints to do this? > > > added to the RTL, so that the second scheduling pass can see them. The prologue and epilogue will include load and store instructions. If you want to instrument them, then you need to run after prologue and epilogue generation. Perhaps you don't need to instrument those particular loads and stores, or perhaps you can run your instrumentation pass twice. Ian
RE: CSE removing a load that is necessary
On 27 July 2007 18:24, Ian Lance Taylor wrote:
> "Pranav Bhandarkar" writes:
>
>> I am working on a private port and am seeing the following problem.
>> For a function returning a double the value is stored by the function
>> in memory. cse removes one of the two loads (to retrieve this returned
>> value) after the function is called.
>>
>> cse modifies insn 48 as
>>
>> (insn 48 47 50 2 test.c:388 (set (reg:SI 180 [+4 ])
>> (reg:SI 178 [+4 ])) 44 {*movsi} (expr_list:REG_LIBCALL_ID
>> (const_int 2 [0x2]) (expr_list:REG_EQUAL (float:DF (reg:SI 136 [
>> D.1517 ])) (nil (nil
>>
>> and also replaces every subsequent use of (reg:SI 180 [+4 ]) with
>> (reg:SI 178 [+4 ]) thus making the above load dead, which gets
>> subsequently removed. This way the result of the function call is
>> lost.
>> My take is that insn 48 should have a REG_RETVAL note ( Infact it
>> does have this but the note is removed by lower_subreg) and cse should
>> be careful when REG_RETVAL and REG_EQUAL appear in the same insn. Is
>> this the right way of going about it ?
>
> Am I reading your code correctly when it appears that the
> __floatunsidf function returns a value in memory rather than via a
> register?
>
> If lower-subreg split up the load from memory, then it was correct to
> remove the REG_RETVAL note. There may be a bug here in that it should
> also remove the REG_EQUAL note in that case. It may be that
> remove_retval_note needs to look for and remove a REG_EQUAL note.
Or perhaps this could be another manifestation of the "cse gets confused by
reg_equal notes on subparts of dimode pseudos if no movdi pattern is defined
in the backend" bug[*]? Pranav, is there a movdi pattern in your backend?
There needs to be one, gcc does get it wrong if you rely on it to break
everything down to si-sized movs.
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: Creating gcc-newbies mailing list
On Fri, 2007-07-27 at 05:30 -0400, Robert Dewar wrote: > People asking *language* questions are often told to go > elsewhere, and that's reasonable. Actually my complaint there > would be that too often, people on this list answer such off > topic questions (which is fine), and copy the answers to the > list (which is not so fine, since it causes more off-topic > posts). The only reason I have cc'ed the list on such replies in the past is so that other list members know that the question has been answered in some shape or form and to avoid redundant work in generating replies. I've not seen short two message threads to be a big problem, but I suppose we could adopt the practice of replying in private (but then we might have five people doing that). Ben
Should gcc/DEV-PHASE in gcc 4.2 branch be updated?
Hi Mark, According to gcc/ChangeLog, gcc 4.2.1 was released on 2007-07-19. Shouldn't gcc/DEV-PHASE in gcc 4.2 branch be marked as prerelease? H.J.
How to activate instruction scheduling in GCC?
Hi ALL I'm a pure beginner in GCC, and currently working on a project to implement instruction scheduling for a new DSP processor. This processor doesn't have pipeline interlock, so the compiler HAVE to schedule the instruction without relying on hardware help anymore The problem is, I'm a very beginner in GCC. I think the scheduling in GCC is activated by INSN_SCHEDULING variable (in automatically generated file: insn-attr.h), but I don't even know how to activate this variable. Any help would be appreciated -- View this message in context: http://www.nabble.com/How-to-activate-instruction-scheduling-in-GCC--tf4167590.html#a11857079 Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: How to activate instruction scheduling in GCC?
petruk_gile <[EMAIL PROTECTED]> writes: > I'm a pure beginner in GCC, and currently working on a project to implement > instruction scheduling for a new DSP processor. This processor doesn't have > pipeline interlock, so the compiler HAVE to schedule the instruction without > relying on hardware help anymore > > The problem is, I'm a very beginner in GCC. I think the scheduling in GCC is > activated by INSN_SCHEDULING variable (in automatically generated file: > insn-attr.h), but I don't even know how to activate this variable. INSN_SCHEDULING will automatically be turned on if you have any define_insn_reservation clauses in your CPU.md file. See the "Processor pipeline description" documentation in the gcc internals manual. That said, the gcc scheduler unfortunately does not work very well for processors which do not have hardware interlocks. The scheduler will lay out the instructions more or less optimally. But the scheduler has no ability to insert nops when they are required to satisfy interlock constraints. I know of two workable approachs. You can either insert the required nops in the TARGET_MACHINE_DEPENDENT_REORG pass or in the TARGET_ASM_FUNCTION_PROLOGUE hook. I personally prefer the latter approach, as it takes effect after all other instruction rearrangement is complete, but there are existing backends which use the former. For an example of inserting nops in TARGET_MACHINE_DEPENDENT_REORG, see the MIPS backend, specifically mips_avoid_hazards. For an example of inserting nops in TARGET_ASM_FUNCTION_PROLOGUE, see the FRV backend, specifically frv_pack_insns. Ian
Re: Refactoring tool
You are right about C, but i believe templates in C++ make parsing harder. DOxygen also parses C/C++. On 7/29/07, Rafael Espindola <[EMAIL PROTECTED]> wrote: > > Having spent some time looking at the code for gcc it seems reasonably > > easy(with some suggestions) to traverse the tree generated and > > write the relevant information to a file. Any suggestions or pointers to > > related work would be much appreciated. > > For C and C++, it might be easier to use a stand alone parser. > Depending on what you want, these might be sufficient: > > http://llvm.org/cfe/ > http://www.cs.berkeley.edu/~smcpeak/elkhound/sources/elsa/ > > > Patrick > > Cheers, > -- > Rafael Avila de Espindola > > Google Ireland Ltd. > Gordon House > Barrow Street > Dublin 4 > Ireland > > Registered in Dublin, Ireland > Registration Number: 368047 > -- 11101010 - it's a way of life
