spee@qmfl.jrdc.go.jp (Paul SPEE) (02/22/90)
In article <9002201535.AA20807@curley.osf.org.osf.org> meissner@osf.org writes: >I've redirected the answer to this question to the bug mailing >list/newsgroup, since questions about compiler internals are best >handled there. I feel bugs are bugs and questions on internals don't belong here. But it is a matter of personal taste. >| I've some questions on gcc: >| As I see it, gcc basicly depends on the named patterns, other patterns >| seem to be ok if they exist, but they don't really seem to effect any of >| gcc (except the combiner pass). Thus it seems, that unnamed patterns are >| there for optimization only. > >Mostly true. If the named pattern is supplied by a define_expand, you >must have an unnamed pattern that matches the pattern(s) emitted by >the define_expand. Also, if you have unnamed patterns that are >similar to the named patterns, except for constraints, these will also >get matched in insn-recog.c. Otherwise, yes, only the combiner will >see the unnamed patterns, and it is only called when optimizing. Section 12.9 "Interdependence of Patterns" mentions several cases where unnamed patters may be required: reversed branches, constant folding. New patterns might be generated by cse. >| Is this right or does the gcc backend check the availability of certain >| patterns to select optimization strategies? > >It checks the named patterns via #ifdefs. It will check unnamed >patterns that are more restrictive than named patterns if they match >the constraints. Named patterns are used during the rtl generation (stmt.c expr.c expmed.c optabs.c). All patterns (define_insn) can be used during optimization and code generation. Peephole optimization (define_peephole) patterns are only used during code generation. >| What kind of code must the gcc front end emit? Is it ok to output >| arbitrarily complex trees on the assumption that the backend can handle >| it? May a front end for example emit code like: >| >| ( set ( reg:SI 10) >| ( plus:SI (reg:SI 40) >| (div:SI (reg:SI 30) >| (reg:SI 50)))) > >A front end could emit a complex pattern like that, and insn-recog.c >would recogonize it. It might defeat some low level optimizations, >like hoisting code out of loops (if, for example, regs 30 & 50 are >constant within the loop, and 40 is variable, and the above pattern >was emitted, the insn will not get hoisted out of the loop). Why would the front end generate such pattern. It could generate (set (reg:SI 20) (div:SI (reg:SI 30) (reg:SI 50))) (set (reg:SI 10) (plus:SI (reg:SI 40) (reg:SI 20))) Loop optimization is done before the combine phase. If 30 & 50 are constant, the loop optimization phase will move the instruction outside the loop, else the combiner can combine both instructions into the previous more complex instruction. >I believe that the combiner has a limit of 3 INSNS that it will >merge. I know I ran up against the limit when I was working on the >88k backend at one point, when I wanted to merge 4 insns into one >machine instruction. I am not sure about this, but isn't the combined pattern again used in combining with other patters. If this is true, a pattern combining 4 insns can be used if a pattern for a subset (2 or 3 insns) exist. Paul Spee _______________________________________________ ______________________ | | | | Paul Spee | ____|___|____ | | Research Development Corporation of Japan | __ | | __ | | Quantum Magneto Flux Logic Project | |__| _|_ |__| | | Computer Architecture Group | |__| _|_ |__| | | c/o Mitsui Zosen System Research | | |_|_| | | | 5-6-4, Tsukiji, Chuo-ku, Tokyo, Japan | | |_|_| | | | Tel. 03-546-7587, Fax. 03-546-7588 | | /|\ | | | spee%jrdc.go.jp@RELAY.CS.NET | | / | \ | | |_______________________________________________|______________________| #include <disclaimer.h>