Re: Legitimize address, Please HELP!

[dimmy <diwil@mail.ru>]

Jan,
thanks

But still some thingsa are not clear:

>2) the zero_shifted/indexed_location test probably should be hid
>   in new operand writen in your md file used in patterns instead of
>   general_operand to make thinks cleaner.
>   Basically the condition should mention only tests that depdends
>   on multiple
>3) "m" is wrong constraint for general_operand. Eighter you need
>   to use memory_operand, or allow some registers and constants
>   in the constraint.
>
If any type of addressing mode is allowed for instruction, I do not know 
how to combine
memory_operand, register and immediate. I can probably write my own 
predicate. Correct?

>   The constraints and predicates should be in "harmony" one should
>   not be considerably stronger/weaker than the other otherwise you
>   are asking for problems in reload pass.
>   In case the second pattern is expected to load address as integer
>   value (i386 lea equivalent), it should use
>   (match_operand "address_operand" "a"), not memory and should come last
>   to avoid matches in dumb cases.
>   
>4) For speed you should probably move more probable movhi3 first.
>5) All three patterns can be single pattern with multiple alternative
>   output template.  This will result in faster compiler and better
>   produced code if you do so.  Some late passes, as reload, do not
>   take a look if different pattern match, only test if given pattern
>   and usually also alternative, allow the suggested optimization.
>6) Similary you can collapse multiple alternatives to single:
>   "=m,r,r,m,r,m,m,r
>     m,r,P,P,m,r,i,i"
>   can be:
>   "=m   ,r"
>     mrPi,mrPi"
>
The instruction length depends on addressing mode.
So, mem->mem has length 3, mem->reg - 2, reg->reg -1, etc.
O course, I can collapse constraints into:
"=mr"
"mrPi"
and then dig an addressing mode. (What type of predicate should I use 
then? general? memory? ...)

 So, will be correct the following:

(define_insn "*movhi3"
 [(set 	(match_operand:HI 0 "nonimmediate_operand"      "=mr")
	(match_operand:HI 1 "general_operand"           "mrPi"))]

""
"* return msp_emit_movhi3(insn, operand, NULL);"
 [(set_attr "length" "3")
   (set_attr "cc" "none")])

and inside msp_emit_movhi3() issue assembler instructions and set up the 
insn lenght as third parameter?
I actually do that for SI and DI modes, but I thought that coding in .md 
is a bit cheaper.



>
>   Also it is good to prohibit mem->mem move in the conditional + add
>   expander to split it into two instructions early like i386.md does.
>   Otherwise the need for register in this case is discovered late in
>   the register allocation progress often resulting in dumb spill.
>
Only in conditional code? Do you mean if I have to compare 2 mem 
locations like
a==b first I have to move one of them to register?
It seems to me that it's cheaper to do
    cmp &a, &b    ;    compare values at addresses a and b
than
    mov &a, r4
    mov &b, r5
    cmp r4, r5

Am I wrong?

>
>In case you do have flags register (as cc attribute suggest), please
>consider not using cc0, as it looks you do use.  We are tying to zap
>that.  Look at i386.md/sparc.md about how new backends are usually
>done.
>
could not get it. What do you mean?


>
>Concerning your problem.  The problematic piece of code is not
>contained in the mov expander, instead it is, most probably, some
>other code generating the add/mov directly and getting thinks wrong.
>
The cpu core contains only 27 instructions and all instructions looks 
the same - for example
'mov' has the same addressing modes as 'add', 'tst', etc... I dump rtl 
phases I could not find where
this instruction being generated.

>
>one of ways to get it is to add test for current_insn_uid in emit-rtl.c
>and break program in debugger when offending instruction is emit. Then
>you will be probably able to figure out where it incarned.
>
nothing much there...

>
>See the gcc readings page.  I believe there are some links to other porting
>docs, than the gcc manual itself.  it is good idea to read them (even when I
>never did :), because it can save you some headaches later.
>
nothing much there eather :)

Thanks
Dmitry.

>
>Hope this helps,
>Honza
>
>>========================
>>(define_expand "movhi"
>> [(set (match_operand:HI 0 "nonimmediate_operand" "")
>>       (match_operand:HI 1 "general_operand" ""))]
>> ""
>> "")
>>
>>
>>(define_insn "*movhi1"
>> [(set (match_operand:HI 0 "memory_operand"      "=m")
>>       (match_operand:HI 1 "general_operand"           "m"))]
>> "( memory_operand(operands[0], VOIDmode)
>>       && !register_operand(operands[0], VOIDmode)
>>       && zero_shifted(operands[1])       
>>       && indexed_location(operands[1]))" 
>>"mov\\t@%E1, %0"
>> [(set_attr "length" "3")
>>  (set_attr "cc" "none")])
>>
>>
>>(define_insn "*movhi2"
>> [(set (match_operand:HI 0 "register_operand" "=r")
>>       (match_operand:HI 1 "general_operand"      "m"))]
>> "(nonimmediate_operand(operands[0], VOIDmode)
>>               && zero_shifted(operands[1])  
>>               && indexed_location(operands[1]) )"
>>      "mov\\t@%E1, %A0"
>> [(set_attr "length" "2")
>>  (set_attr "cc" "none")])
>>
>>(define_insn "*movhi3"
>> [(set (match_operand:HI 0 "nonimmediate_operand"      "=m,r,r,m,r,m,m,r")
>>       (match_operand:HI 1 "general_operand"           " 
>>m,r,P,P,m,r,i,i"))]
>> "(nonimmediate_operand(operands[0], HImode)
>>       && !zero_shifted(operands[1])
>>       && !indexed_location(operands[1]) )"
>> "mov\\t%1, %0 "
>> [(set_attr "length" "1,3,1,2,2,2,3,2")
>>  (set_attr "cc" "none")])
>>==============================
>>
>
>