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

[John Thompson]

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) 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/2d626829/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/2d626829/attachment.obj>