On Mon, Jun 26, 2006 at 04:16:28PM +0200, Roland Persson wrote:
> Hi,
> 
> My target has some instructions that do not exactly match any predefined
> pattern names. What is the correct way to get gcc to use them in code
> generation?

Please see <URL:http://gcc.gnu.org/onlinedocs/gccint/Patterns.html>.
 
> For example, I have an add instruction that can add a 32-bit integer (with
> or without sign extension) to a 64-bit operand and store the result as 64
> bits.
[cut]
> I've tried adding unnamed patterns for these instructions, using
> zero_extend or sign_extend but I guess those will not get used because the
> generation has already applied the adddi3 pattern when it generates the RTL
> in the first place.

In a similiar case, only with 8 and 16 bits, respectively, I'm having success
with this pattern, which you could use as a starting point:

(define_insn "*zero_extendqihi_addhi3"
  [(set (match_operand:HI 0 "nonimmediate_operand" "=q,m")
        (plus:HI (zero_extend:HI (match_operand:QI 1 "general_operand" 
"qmi,qi"))
                 (match_operand:HI 2 "nonimmediate_operand" "0,0")))
   (clobber (reg:CC CC_REG))]
   ""
...
)

(It would have been a help to us to see examples of insn patterns you have
tried unsuccessfully.)

You will need to enable code optimization. The optimization pass you want
in this case is named "combine". You should consult the manual so you know
what sort of optimizations you can expect.

In addition to the instruction pattern, you may have to adjust the RTX cost
calculation (TARGET_RTX_COSTS) so that the optimizers know if this
instruction is cheaper than two individual instructions. This is not
difficult as such, but can be a lot of work if you want to do this for all
instruction patterns and get reasonably accurate costs.

The only really difficult part is knowing which patterns combine is looking
for. AFAIK, there is no way, short of patching combine, to make combine
reveal such important information. Some sort of clue is given by
<URL:http://gcc.gnu.org/onlinedocs/gccint/Insn-Canonicalizations.html> but
is not the whole story.

-- 
Rask Ingemann Lambertsen

Reply via email to