This is the mail archive of the
mailing list for the GCC project.
Re: gcc port to StarCore
BINGO. The RTL dump would have shown us an UNSPEC in the chain AND
the compiler doesn't know
ANYTHING about UNSPECs. [Gee, it might be a good thing to add a
"remark" to the Porting guide near the definition and examples of
UNSPEC to warn people about this - I remember it biting me about 5
years ago while working on the SHARC port.]
You really don't want to use UNSPEC for things that have any
"reasonable" semantic meaning
that can be expressed in the standard RTL.
At 5:36 PM +0200 5/2/02, David Livshin wrote:
> > 2/ the DEFINE_INSNs for compares
>after expanding "cmpsi" as described above I expand conditional jumps ( e.g.
>"bgt" ) emitting, among other things,
> emit_insn( gen_cmpsiEXPANDED( StarCore_cmp.op0, StarCore_cmp.op1,
> GEN_INT( ( int )cndt_code ),
> gen_reg_rtx( SImode ) ) );
>( define_insn "cmpsiEXPANDED"
> [ ( parallel [ ( unspec:SI [ ( match_operand:SI 0 "drREG_operand" "d,z" )
> ( match_operand:SI 1 "drREG_operand" "d,z" )
> ( match_operand:SI 2 "immediate_operand" "" )
> ( set ( cc0 ) ( match_operand:SI 3 "" "" ) )
> "* return (char *)StarCore_DefineInsn_cmpsi( operands, insn );"
>with StarCore_DefineInsn_cmpsi being routine that just emits StarCore
>Is "unspec' what is preventing constant holding in compare?
Quality Software Management
Software Process Improvement / Management Consulting
Language Design / Compiler Implementation