This is the mail archive of the
cgen@sourceware.org
mailing list for the CGEN project.
Re: delayed branches and zero overhead loops
On Wed, Feb 14, 2007 at 12:08:21PM -0500, Dave Brolley wrote:
> Joern Rennecke wrote:
>
> >On Tue, Feb 13, 2007 at 04:11:52PM -0500, Frank Ch. Eigler wrote:
> >
> >
> >>The decoder generator is fully automatic. If you represent decodable
> >>bits without cheating, it will do a reasonable job.
> >>
> >>
> >
> >I which that were the case. Try to generate the decoder for the attached
> >file; it warns about one alledged Decoder ambiguity for j_L_r_r
> >[$RC-noilink]
> >versus j_L_r_r [$RC-ilink] . The values for $RC-ilink and $RC-noilink are
> >disjoint. I've also tried to use a decode-split on this problem, but to
> >no avail.
> >
> >
> The problem is that RC-ilink and RC-noilink are operands. They do not
> participate in insn decoding. If there are no other differences in the
> fixed fields of the insns (it's hard to tell because of the complexity
> of your pmacros),
That is indeed the case. The only format differences are in the
RC-ilink / RC-noilink operand and in the F0 / F1F operand.
> then there will be an ambiguity.
It's the same situation with long immediates. They are indicated by a
special value in any one of three operand fields.
> If you add enough
> "-v"s to CGENFLAGS when you run your make, you will get a dump of the
> pmacro-expanded input.
The debug output without any -v is already too much to be read, unless
it is captured with script and then searched for specific items.
If I want to know the expansion of a single macro, I find it more useful
to use pmacro-expand interactively - the latency is also much lower than
to rm -rf the entire build tree and then rebuilding.
Speaking of which, is there a better way? I've tried deleting individual
generated files or stamps, and some clean targets, but make always
floundered.