Re: Possible bug in regrename.c???

["Marty Hauff" <marty dot hauff at rmit dot edu dot au>]

>>> Anders Ådland <aaadland@atmel.no> 07/29/03 19:26 PM >>>
>movhi is accepting all general operands, which makes >GCC able to generate 
>this pattern. Use a predicate function and constraint >letters to restrict 
>which patterns movhi is accepting. The avr port is >dividing movhi into a 
>define_expand and a define_insn, which is a good >solution.

OK Its time I added some more information....

I am a PhD student researching into the possibility of using a compiler to determine what machine resources would be needed by a given application.  My strategy is to examine the insn list created by GCC to determine what insns are being called for.  I have modified GCC to the point that I can track which standard pattern insns are used to create the initial insn list.  In order to give GCC free reign, I have included ALL standard pattern insns into the machine description file and I have removed virtually all constraints from each insn.  In a sense, I am offering GCC the world (as far as resources go) to see what it chooses.

My movhi insn is totally unconstrained for the above reasons and from my point of view this is legal. My problem is that when given this insn template, GCC creates an insn that it doesn't know what to do with.  The documentation (GCC Compiler Collection Internals) suggests that the expression (pre_dec:m x) requires x to be EITHER a reg or mem, but most machines only allow a reg.  From what I can see of kill_autoinc_value(), it assumes x will only ever be a reg.  Either the documentation or the code is wrong (IMHO).

Marty Moose