<div>Dale, thanks for your response on llvm-dev.  I'm moving the discussion here since the brainstorming in the latter part has to do with Clang.</div>
<div> </div>
<div>My coworker here (who you know, but I won't mention here) feels that alternative constraint selecting needs to be done in the backend, since it's hard for the front-end to know the current state of things.  Here's what he said in two emails:</div>

<div> </div>
<div>> I may misunderstand (because this stuff is very complicated), but I think that the only time the alternatives can be chosen is when code generation happens. For example, if one alternative is "r" and the other is "m" then you need to know if the value is in a register or memory to choose and that decision isn't made until much later than Clang interacts with. The problem with looking at llvm-gcc or gcc in general is that they mix up the front and back ends freely and the lines are very gray.</div>

<div> </div>
<div>and (refering to some code with alternative constraints "r,K" (old_value)):</div>
<div> </div>
<div>> My question still stands -- how can a constraint be selected that early and be accurately fulfilled? In this case, I'm asking if old_value is a constant that fits in 16-bits. You only know that in the backend -- the function may get inlined, etc. In GCC, this happens inside reload which is really late.</div>

<div> </div>
<div>Any thoughts?</div>
<div> </div>
<div>I did look at ChooseConstraintTuple, which seems to treat the constraints like this.  Ignoring the names and expressions, if I have set of constraints like this:</div>
<div> </div>
<div>"=a,=b", "c,d", "e,f"</div>
<div> </div>
<div>it will look at expression types and do weighting to select one or the other of the two alternatives, i.e. either:</div>
<div> </div>
<div>"=a", "c", "e"</div>
<div> </div>
<div>or</div>
<div> </div>
<div>"=b", "d", "f"</div>
<div> </div>
<div>First, do I understand this correctly?</div>
<div> </div>
<div>If this is the case, then Clang should concatenate the set chosen and put it in the LLVM asm statement output.  For example, if the first was chosen, then the following would be output to LLVM;</div>
<div> </div>
<div>"=a,c,e"</div>
<div> </div>
<div>
<div>Meanwhile, I have been trying to persue it on the Clang side. Here's some description of what I've been doing and what my original thoughts were.</div>
<div> </div></div>
<div>In trying to come up with a solution for the inline asm multiple alternative constraints inside Clang, my first step was to try come up with a representation that wouldn't require much change to other parts of Clang, but then I started thinking that perhaps the structure of AsmStmt could be improved, per the FIXIT comment already in it.</div>

<div> </div>
<div>But first, the enclosed patch shows what I've been playing around with already with respect to ConstraintInfo.</div>
<div> </div>
<div>It might be unclear in the patch, with the interleaving, so here's a high-level description.  What I did was to change the ContraintInfo class in the TargetInfo to be two classes, ConstraintInfo and SubConstraintInfo, where ConstraintInfo stores an array of SubConstraintInfo's, i.e.:</div>

<div> </div>
<div>class SubConstraintInfo  // for each constraint alternative<br>{<br>    const char *getConstraintStr();<br>    // ...<br>};</div>
<div> </div>
<div>class ConstraintInfo<br>{<br>    SubConstraintInfo subConstraints[4];<br>    int count;<br>    int selectedIndex;<br>    const char *getConstraintStr() { return subConstraints[selectedIndex]; }<br>    // ...<br>};</div>

<div> </div>
<div>where the two class have similar functions.  Then my thinking was that the semantic analysis can analyse the multiple alternative constraints based on the expression typing, and set up the outer class to return only that info by setting the selectedIndex. (I haven't done that part yet.  Right now it just uses the first alternative.)</div>

<div> </div>
<div>I did it this way to minimize the effect on the code using the previous (1-layer) ConstraintInfo class.  Once the alternatives are chosen, the class is used just as before (mostly, with a small change to the code generator, which wasn't using the constraint string from ConstraintInfo.</div>

<div> </div>
<div>But in trying to figure out how to do the analysis part, I've been starting to feel that a bit of an overhaul of the AsmStmt might provide a cleaner structure.  The current AsmStmt stores the components of separate lists, i.e. the expressions for the in/out, the name structures, and the raw constraint strings, and as the FIXME comment indicated, perhaps it might be better to group them into an array of structures, additionally replacing the raw constraint strings with something like the above ConstraintInfo moved to AST and also stored in AsmStmt, such that the code generator wouldn't have to parse the constraints a second time on the fly from the raw constraint strings.</div>

<div> </div>
<div>I'm thinking also that more of the information from the constraints could be abstracted from the constraint strings.  Currently there's no indication of something being a constant or float or the size.  I'm thinking some of the architecture-specific constraints could be abstracted too in a way shared by multiple architectures.  These would be set up by the Target-specific constraint validation functions.<br>
</div>
<div>But perhaps the first step would be to do the easier thing, and add an analyser somewhere to try to select the best matching constraint.  I'm not quite sure how to do that yet, but I hoping hoping for some feedback before I get too much deeper into it, to make sure I'm in the right direction.</div>

<div> </div>
<div>So, if others would also like to comment also, please do.  Again, the questions are:</div>
<div> </div>
<div>Should the constraint selection be done in LLVM or Clang?</div>
<div> </div>
<div>If in Clang, is my approached described a reasonable one, first the quick one using the ConstrainInfo created on-the-fly, perhaps followed by reworking AsmStmt a bit to store the abstracted constraint info in AsmStmt?</div>

<div> </div>
<div>Thanks.</div>
<div> </div>
<div>-John</div>
<div><br>-- <br>John Thompson<br><a href="mailto:John.Thompson.JTSoftware@gmail.com">John.Thompson.JTSoftware@gmail.com</a><br><br></div>