[LLVMdev] [REQUEST FOR FEEDBACK] Inline asm multiple alternative constraints

John Thompson john.thompson.jtsoftware at gmail.com
Wed Aug 25 12:45:21 PDT 2010


Hi,

I'm looking for some feedback on the changes represented in the attached
patches, which I'll describe below.

I'm sending this to both the LLVM and Clang list because it affects both,
though the main focus here is LLVM.
Basically, I've partially implemented some changes for choosing multiple
alternative constraints largely on the LLVM side.

The Clang change is to output the multiple constraints using a '|' character
in the constraint strings to delimit the alternatives.

The LLVM change is as follows.

In an earlier attempt, I just hacked up SelectionDAGBuilder::visitInlineAsm,
and pretty much used the same logic in
TargetLowering::ComputeConstraintToUse/ChooseConstraint.  But then
I discovered that InlineAsm::ParseConstraints was called in a couple of
other places, and in one of those places (IsOperandAMemoryOperand in
AddrModeMatcher.cpp), there wasn't a DAG pointer handy (at least I don't
think there is, as I'm not too familiar yet with LLVM internals), which
meant that I needed to handle multiple alternative constraints in other
places besides just SelectionDAGBuilder::visitInlineAsm.

Basically I see that there are three layers of contraint info classes,
SDISelAsmOperandInfo -> AsmOperandInfo -> ConstraintInfo.  Therefore, I
implemented a different scheme, putting a ParseConstraints function in
TargetLowering that returns a vector of AsmOperandInfo objects, and which
will do the constraint selection without needing the DAG.  I'm assuming the
value info in the operands from the callsite object is sufficient to choose
the constraints.  I also added some other virtual functions to
TargetLowering to allow the different targets to handle the target-specific
contraints.  At present, I only overrode the getSingleConstraintMatchWeight
function in X86TargetLowering, and just for one constraint letter, as an
example.

In the three places where the original InlineAsm::ParseConstraints was
called (CodeGenPrepare.cpp, AddrModeMatcher.cpp, and SelectionDAGBuilder), I
replaced the calls with calls to TargetLowering::ParseConstraints, and
revised the loops over the constraints accordingly, which were still needed
to set up SDISelAsmOperandInfo objects or get other information the code was
looking for.  SelectionDAGBuilder::visitInlineAsm I especially reordered bit
at the front, to make things work.  I left in a little bit of overlap in the
setting of the CallOperandVal member in the first for loop, which I could
factor out, as I really just need the output and input counts.

Bascially, I wanted to get some feedback before I went too much farther down
this road.  I think the main work left is to add support for all or some
subset of both the generic and target-specific constraints, and to write
tests for them all.

Since I had trouble with running tests on a Windows box, I set up a Linux
box so I could run the regression tests.  The tests still pass with these
changes.

So, my main question is, am I on the right track?  And either way, specific
information on problems would be appreciated too.

Another question concerns the weighting I used for choosing the
constraints.  Bascially I pretty much used the same prioritization used in
TargetLowering::ComputeConstraintToUse/ChooseConstraint, which will chose
memory operands over register.  I would have thought a register operand
would have been a better choice over memory, but then that raises the
question of whether you can know what's already in a register when this
instruction is reached.  I haven't gotten deep enough to know yet.  I assume
it's like this because it is more likely to be a correct fit, if not
optimal.

It seems that if the value info in the operands from the callsite object is
sufficient to choose the constraints, the
ComputeConstraintToUse/ChooseConstraint function could also use this scheme,
probably just calling the same get weight functions, to be a bit more
efficient.  I left it alone for now, because I know it works as it is.

Thanks!

-John

-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100825/babd916a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvmmultalt6.patch
Type: application/octet-stream
Size: 29572 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100825/babd916a/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clangmultalt6.patch
Type: application/octet-stream
Size: 2233 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100825/babd916a/attachment-0001.obj>


More information about the llvm-dev mailing list