Dale,
I've looked a bit at ChooseConstraintTuple in llvm-gcc, as well as the code
generator in Clang and the inline asm handling in LLVM (ala visitInlineAsm).
While I see how Clang could do it to some extent by looking at the
expression types of the operands, it seems that LLVM would be in a better
position for choosing multiple alternative constraints as it would know what
all the operands are, and where they currently are, particularly if part of
an earlier transformation resulted in operands Clang thought were in memory
were already in registers. And LLVm might need to step in anyway if
registers can be allocated.
Or is the constraint handling always performed before such changes as these
would be made, such that Clang could know this?
Or for a more off-the wall question, could asm constraints just be ignored,
and let the target code in LLVM choose the appropriate instruction opcodes,
and provide any additional piping needed to get the operands in and out of
the given assembly instructions?
But I guess that would be way more complicated than just selecting the
best-matching constraint alternatives.
What I learned from ChooseConstraintTuple in llvm-gcc is that the
constraints need to be considered in parallel. That is, you collect the
first alternative of each constraint string, give it a weight value,
including a value meaning the combination won't work, collect the second
alternative of each constraint string, give it a weigh, and if better than
the first, save it, and so on for each constraint string, finally using the
one with the best weight, or erroring if none match at all.
This would require a few things:
1. Clang needs to properly output the constraints. I recently changed Clang
to only output the first alternative, as it was outputting the comma, which
confused the code generator. Since apparently multiple constraint letters
can be used (not the true multiple-alternative constraints), we probably
would need to put in some separator character, such as a vertical bar
character ("|") to delimit the constraints. I think I even saw a
mention of
"|" at one point in looking at the LLVM code, as if maybe it was
considered
at one time, but I couldn't tell what it applied to.
2. Clang might need some change to the constraint representation with
respeced to the logic it uses to determine if an operand is to be indirect
(using "*"), because seeing "r" and "m" in
alternatives results in both the
"allowsRegister" and "allowsMemory" flags being set, and the
allowsMemory
flag is used to add the indirect flag. However, I saw code in LLVM that
will insert code for the indirection even if the indirect flag is not
present, such that I think we might be able to eliminate that flag and let
LLVM deal with it.
3. LLVM needs code to select the alterinative constraint to use. To do
this, the inline asm handler probably needs to be changed to store the
alternatives separately to make it easier to walk them for the selection,
perhaps using a SubConstraintInfo class in an array owned by
ConstraintInfo. After the selection, which determines the one subconstraint
index needed, the data for the selected alternatives could then be copied to
the ConstraintInfo class to reduce impact on the code using it.
I'm willing to have a go at doing this myself, but I think it might be
beyond me, particularly since I have no experience modifying LLVM yet, and
this is a pretty hairy section. So it would be great if you or Chris or
whoever really knows this code could take it on.
Of course, this is just my initial brainstorming proposal, to see if you
guys would agree that the back-end is more appropriate for the alternative
constraint selection.
-John
On Thu, Jul 29, 2010 at 11:41 AM, Dale Johannesen <dalej at apple.com>
wrote:
> The LLVM asm parser doesn't support multiple alternative constraints;
you
> need to have Clang pick one tuple in the front end. See
> ChooseConstraintTuple in llvm-gcc for prior art.
>
> On Jul 29, 2010, at 11:36 AMPDT, John Thompson wrote:
>
> I'm trying to fix the handling of multiple alternate constraints in
> Clang (see
>
http://gcc.gnu.org/onlinedocs/gcc/Multi_002dAlternative.html#Multi_002dAlternative
> ).
>
> How should the constraints be represented in the .ll file?
>
> Clang currently will assert because the code generator sees a constraints
> string with the wrong number of comma-separated items.
>
> Basically, after some editing, it just concatenates them together. The
> commas used in the string for a multiple alternative constraint gets
> confused with the commas separating the constraints.
>
> Briefly looking at the LLVM asm parser, I can't really see anything
that
> tells me multiple alternative constraints are supported.
>
> But if they are, please tell me the string format, and perhaps update the
> docs to show this.
>
> If they are not yet supported in LLVM, what should I do?
>
> -John
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
--
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100813/13c3a30a/attachment.html>