[cfe-commits] [QUESTION] - asm multi-alt constraints, AsmStmt reworking

[Dale Johannesen]

On Jul 29, 2010, at 3:57 PMPDT, John Thompson wrote:

> 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.
>
> My coworker here (who you know, but I won't mention here)

Hmm, who could need such protection?  Can't think of anyone....

It depends what your goal is.  If you're after 100% compatibility with  
gcc, you're probably right that the existing implementation doesn't  
cut it.  But constraints are basically a user hook into the internals  
of gcc's register allocator, and llvm's is completely different; I  
don't that's an achievable or particularly desirable goal.  This was  
sufficient to handle all existing asm code at Apple in a functionally  
correct fashion, although not necessarily producing the same code gcc  
does.  In fact, I was expecting to have to revise it after the initial  
implementation, but I have not had to do that.

A lot of people regard inline asm as a necessary but undesirable  
backward compatibility hack, and some haven't given up hope it can be  
made to go away some day.   So there's not much interest in putting a  
lot of effort into it.

I think you should define what you're trying to accomplish before  
getting too deep into this.  It is very messy.

> 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:
>
> > 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.
>
> and (refering to some code with alternative constraints  
> "r,K" (old_value)):
>
> > 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.
>
> Any thoughts?
>
> 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:
>
> "=a,=b", "c,d", "e,f"
>
> it will look at expression types and do weighting to select one or  
> the other of the two alternatives, i.e. either:
>
> "=a", "c", "e"
>
> or
>
> "=b", "d", "f"
>
> First, do I understand this correctly?
>
> 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;
>
> "=a,c,e"
>
> 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.
>
> 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.
>
> But first, the enclosed patch shows what I've been playing around  
> with already with respect to ConstraintInfo.
>
> 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.:
>
> class SubConstraintInfo  // for each constraint alternative
> {
>     const char *getConstraintStr();
>     // ...
> };
>
> class ConstraintInfo
> {
>     SubConstraintInfo subConstraints[4];
>     int count;
>     int selectedIndex;
>     const char *getConstraintStr() { return  
> subConstraints[selectedIndex]; }
>     // ...
> };
>
> 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.)
>
> 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.
>
> 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.
>
> 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.
> 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.
>
> So, if others would also like to comment also, please do.  Again,  
> the questions are:
>
> Should the constraint selection be done in LLVM or Clang?
>
> 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?
>
> Thanks.
>
> -John
>
> -- 
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20100729/12c7bfa1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multaltconstraints.patch
Type: application/octet-stream
Size: 10127 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20100729/12c7bfa1/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20100729/12c7bfa1/attachment-0001.html>