http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55523
--- Comment #3 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> 2012-11-29 14:12:53 UTC --- (In reply to comment #2) > Yeah, either you'd need to provide prototype for the function in > epiphany-protos.h, or you shouldn't include those calls in the condition of > the > peephole2, but instead in the C sequence do if (!get_attr_*) FAIL; > Including insn-attr.h in the generated gencondmd.c is not an option, that > would > be a cyclic dependency (as insn-attr.h generation depends on > insn-conditions.md > and insn-conditions.md generation depends on gencondmd.c compilation and that > would need to depend on insn-attr.h). Well, I do declare the get_attr_* function in epiphany-protos.h for now, but I think that's a rather ugly work around. I have to duplicate an auto-generated prototype. And writing an identity wrapper for a generated function and then providing a prototype for the wrapper function isn't really making things any simpler. There is no fundamental reason why we can't generate the get_attr_* prototypes before compiling gencondmd, this is just an artifact of how we structured the generator programs. I suppose using FAIL would solve the dependency issue, but I'm never quite sure what that means. In the context of expanders, it sometimes causes (caused?) ICEs. The documentation gives a list of specific instruction patterns that support FAIL, but doesn't mention peephole2 in this context. Will a recognized-but-FAILed peephole2 cause different decisions on if, an if so, which, other peephole2 patterns can match?
