Re: Legitimize address, Please HELP!

[Jan Hubicka <jh@suse.cz>]

> 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?

memory+register+immediate is general_operand, but yes, if nothing apply,
just write your own operand.

In case your architecture limits constants in all cases (it appears to),
there are macros (LEGITIMATE_CONSTNAT?) or something like that to do
the trick w/o need to write new predicates for everything.
> 
> >  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 

Hmm, then I guess you may try to keep the alternatives and see what
happends.  I've missed the length attribute.

> 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")])

This looks correct.
> 
> and inside msp_emit_movhi3() issue assembler instructions and set up the 
> insn lenght as third parameter?
If you will still use the alternative you can use template with line per
alternative starting by '@'.
> 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?
No, I meant conditional of the pattern (the condition),
but I see your architecture supports mem->mem moves, so the comment is wrong
anyway.
> >
> >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.

All I can advise you is to use debugger and figure out how the instruction
(and invalid operand) is constructed.  Until then without the sources for
port you are working on it is really dificult to tell something.

Honza