On Mon, 9 Oct 2006, Roman Levenstein wrote:> But your previous explanations were so good that I implemented in my > backend last week almost the same that you've done now in the > X86InstrSSE.td. I even introduced isCommutable parameter to indicate > this property, just as you did. So, by now integer arithmetic and > general purpose instructions are implemented. I'm working on the FP > support now.Great :)> Some feedback about tblgen from my side, i.e. an LLVM newcomer with > quite some compiler construction experience:> When it comes to tblgen descriptions and corresponding DAG selection > and lowering code to be written for a backend, I found the use of > InFlag, OutFlag and chains less understandable, very underspecified and > not (well) documented. Even though they are used in all backends, > their semantics and correct use is far from obvious (even though I'm > not new to compiler writing).Right, it is unfortunate that the code generator isn't better documented :(. Patches gratiously accepted :)> I spent most time on getting these things right. And I learned that if > they misbehave it has very fatal consequences on the overall code > selection process. Now it works, but I still don't quite understand > their overall semantics and don't feel very confident about them. And I > guess I'm not the only one. Therefore, I would kindly ask to provide > here on the developers list and may be even in the docs a clear > explanation of these concepts, giving guidelines on their usage and > probably a small, but understandable example making use of them. I think > such a description would make creation of new backends much easier and > faster.Basically, flag operands are a hack used to handle resources that are not accurately modeled in the scheduler (e.g. condition codes, explicit register assignments, etc). The basic idea of the flag operand is that they require the scheduler to keep the "flagged" nodes stuck together in the output machine instructions. If you have a specific question, I'm more than happy to answer it, -Chris -- http://nondot.org/sabre/ http://llvm.org/
> Basically, flag operands are a hack used to handle resources that are not > accurately modeled in the scheduler (e.g. condition codes, explicit > register assignments, etc). The basic idea of the flag operand is that > they require the scheduler to keep the "flagged" nodes stuck together in > the output machine instructions.>From an user point of view, flags have two different uses1) Forcing a value to be in a particular register. 2) As a hack when a machine state is not made explicit. For example, in the ARM backend I haven't declared the "FP status" and the "status" registers. So the FMSTAT instruction needs a flag. It should be possible to remove all uses of 2 by a writing a more complete description. Maybe the uses of 1 could be abstracted with a higher lever interface...> If you have a specific question, I'm more than happy to answer it, > > -ChrisRafael
> > Basically, flag operands are a hack used to handle resources that > are not > > accurately modeled in the scheduler (e.g. condition codes, explicit > > register assignments, etc). The basic idea of the flag operand is > that > > they require the scheduler to keep the "flagged" nodes stuck > together in > > the output machine instructions. > > >From an user point of view, flags have two different uses >> 1) Forcing a value to be in a particular register.How does it do it? I cannot remember that it does so explicitly. Or do you mean that it forces the InFlag argument of an insn to be the same register as the OutFlag of another instruction?> 2) As a hack when a machine state is not made explicit. For example, > in the ARM backend I haven't declared the "FP status" and the > "status" > registers. So the FMSTAT instruction needs a flag.OK. Their usage as a mean to tarnsfer a status directly is more clear now. The insn with incoming flag basically reuses the outflag of another insn. If I understand correctly, any intruction that can change status (usually a status register, or are there any other examples???) should/can produce an OutFlag. And any instruction that can need a flag, should be decalred with InFlag. What about instructions that use status, but do not change it (like conditional jumps) - should they also have an outFlag to indicate that they propagate a status? And what about such instructions like jumps or calls, where chains are used. What is the exact meaning of the chain? What it refers to? Is it a chain of operands? Is it a chain of instructions? How is it propagated? What is a guideline to use it? If a new backend is to be developed, what are the criteria to ecide that a chain should be used for a given instruction? For example, if we have something like: cmp %a, %b jmp lt, label1 jmp gt, label2 call f1 What should be propagated as In/Out flags in this example and what and why should be propagated as chains?> It should be possible to remove all uses of 2 by a writing a more > complete description. Maybe the uses of 1 could be abstracted with a > higher lever interface...-Roman __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com