Re: [avr-gcc-list] split movhi to 2 movqi

[Georg-Johann Lay]

Ilya Lesokhin schrieb:
> it works great, thanks for all the help.
>
> though i have a few more questions and i'd be glad if you could answer them
> for me.
>
> 1. when and by whom  adjust_insn_length(...) is called?

See the sources in avr.h
It's the implementation of a target macro.

> 2. to update my new pattern length all i have to do is recongenise it in
> adjust_insn_length(...) ?

It depends how complicated your length computation is. For easy cases 
the length attribute is ok, note that it is allowed to be fuzzy. To 
reduce overall overhead by insn length fuzzyness, it's presumably best 
to treat it in adjust_insn_length.

> 3. to implement my new code i had to copy the functionality of
> out_movhi_mr_r(...)
> (move from register to mem).
> i wanted to avoid it so at first i change it to work with my new patter (2
> QI registers instead of 1 HI)
> and before calling it from  output_movhi(...) i splitied the register into 2
> using the following:
> ...
> output_movhi
> rtx ops[3];
> ops[0] = operands[0];
> unsigned int low_off = subreg_lowpart_offset (QImode, HImode);
> unsigned int high_off = subreg_highpart_offset (QImode, HImode);
> ops[1]= simplify_gen_subreg (QImode, operands[1], HImode, low_off);
> ops[2] = simplify_gen_subreg (QImode, operands[1], HImode, high_off);
> templ = out_movhi_mr_r (insn, ops, real_l);
> ...
>
> unfourtenly it didnt work and when i tired to compile a big project it
> generated ldd r28, __SP_L__ which is an illigal instruction.
> do you have any idea why that happend?

You have to read and understand the existing sources. You abused the 
implementation/interface of out_movhi_mr_r. $0=dest, $1=src abd $2=clobber

> 4. in the normal code the following appers:
> ...
> if (src == const0_rtx)
> operands[1] = zero_reg_rtx;
> templ = out_movhi_mr_r (insn, operands, real_l);
> ...
>
> since  zero_reg_rtx is an 8 bit register, i'm curious as to how it works?
> if i do something "similar" in inline assembly
> uint8_t value1 =1, value2 =2;
>
> **asm
> (" add %0,%%B1 " "\n\t"
> : "+r" (value1)"
> : "r" (value2);
> :
> );
>
> then the second opperand of the add is the register the is adjecent to the
> one that was allocated for value2, so how come the same doesnt happen with
> zero_reg_rtx  in out_movhi_mr_r(...)?

You are at the bleeding edge, you will have to read the sources.

> 5. can you point me to somewhere that explains how to get the change to be
> accepted to the officail gcc?

Start reading http://gcc.gnu.org/contribute.html

Basically

* The patch has to be GPLed. It's easiest to have a
  FSF copyright assignment on file.

* The soucres must be according to GCC coding rules. Major editors
  support GNU style.

* The patch must come along with an appropriate ChangeLog entry. Major
  editors support changelog mode, so that formatting is easy.

* The patch must be tested against the testsuite. A reasonable
  simulator is avrtest. There has been a thread here just recently
  that contains some links and discussion of some problems/improvements.

* The patch must be "reasonable". E.g. it's unlikely that a patch gets
  approved that invents great deal of hard-to-understand code to improve
  the overall code size by 0.000001 %.
  If a patch is intended to increase performance, it might be helpful
  to do some benchmarking.

* The patch has to be sent to address@hidden
  See http://gcc.gnu.org/lists.html
  It's advisable to CC the respective maintainer(s),
  see MAINTAINERS.

* A maintainer has to approve it and integrate it into GCC.
  To make that easy, the patch sould be applicable without changes, i.e.
  the patch should be against the current (development) head.
  Except for current head, the only changes that are accepted are bug
  fixes and documentation updates.

Johann