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

John Thompson john.thompson.jtsoftware at gmail.com
Mon Aug 30 10:59:15 PDT 2010


Dale,

Thanks for reviewing this.

I have some newbie questions regarding the test-suite for you or anyone:

I'm trying to run the test-suite as described in the "LLVM Testing
Infrastructure Guide" on a Ubuntu x86 64 bit system.  Initially I ran into
problems with missing tools like yacc, which I fixed as I went along until
the make at the test-suite level completed.  However, I get a number of
failed tests:

john at john-ubuntu:~/llvm/projects/test-suite$ grep FAILED\! jttestlog.txt
******************** TEST (jit) 'tls' FAILED! ********************
******************** TEST (llc) 'initp1' FAILED! ********************
******************** TEST (cbe) 'initp1' FAILED! ********************
******************** TEST (cbe) 'ctor_dtor_count-2' FAILED!
********************
******************** TEST (cbe) 'ctor_dtor_count' FAILED!
********************
******************** TEST (cbe) 'exception_spec_test' FAILED!
********************
******************** TEST (cbe) 'function_try_block' FAILED!
********************
******************** TEST (cbe) 'simple_rethrow' FAILED!
********************
******************** TEST (cbe) 'simple_throw' FAILED! ********************
******************** TEST (cbe) 'throw_rethrow_test' FAILED!
********************
******************** TEST (jit) 'ctor_dtor_count-2' FAILED!
********************
******************** TEST (jit) 'ctor_dtor_count' FAILED!
********************
******************** TEST (jit) 'exception_spec_test' FAILED!
********************
******************** TEST (jit) 'function_try_block' FAILED!
********************
******************** TEST (jit) 'simple_rethrow' FAILED!
********************
******************** TEST (jit) 'simple_throw' FAILED! ********************
******************** TEST (jit) 'throw_rethrow_test' FAILED!
********************
******************** TEST (cbe) '2004-03-15-IndirectGoto' FAILED!
********************
******************** TEST (cbe) 'except' FAILED! ********************
******************** TEST (jit) 'except' FAILED! ********************
******************** TEST (cbe) 'bigfib' FAILED! ********************
******************** TEST (llc) 'spirit' FAILED! ********************
******************** TEST (cbe) 'spirit' FAILED! ********************
******************** TEST (jit) 'spirit' FAILED! ********************
******************** TEST (cbe) 'burg' FAILED! ********************
******************** TEST (cbe) 'sgefa' FAILED! ********************
******************** TEST (cbe) 'make_dparser' FAILED! ********************
******************** TEST (jit) 'spiff' FAILED! ********************
******************** TEST (cbe) 'oggenc' FAILED! ********************
******************** TEST (cbe) 'lencod' FAILED! ********************
******************** TEST (cbe) 'SIBsim4' FAILED! ********************
******************** TEST (llc) 'clamscan' FAILED! ********************
******************** TEST (cbe) 'clamscan' FAILED! ********************
******************** TEST (jit) 'clamscan' FAILED! ********************
******************** TEST (cbe) 'sqlite3' FAILED! ********************
******************** TEST (jit) 'lemon' FAILED! ********************
******************** TEST (cbe) 'OpenSSL' FAILED! ********************
******************** TEST (jit) 'OpenSSL' FAILED! ********************
******************** TEST (cbe) 'minisat' FAILED! ********************
******************** TEST (jit) 'minisat' FAILED! ********************
******************** TEST (cbe) 'lua' FAILED! ********************
******************** TEST (cbe) 'Obsequi' FAILED! ********************
******************** TEST (cbe) 'kc' FAILED! ********************
******************** TEST (cbe) 'fhourstones3.1' FAILED!
********************
******************** TEST (cbe) 'bh' FAILED! ********************
******************** TEST (cbe) 'health' FAILED! ********************
******************** TEST (cbe) 'cfrac' FAILED! ********************
******************** TEST (cbe) 'espresso' FAILED! ********************
******************** TEST (cbe) 'gs' FAILED! ********************
******************** TEST (cbe) 'agrep' FAILED! ********************
******************** TEST (cbe) 'archie' FAILED! ********************
******************** TEST (cbe) 'unix-smail' FAILED! ********************
******************** TEST (cbe) 'rawcaudio' FAILED! ********************
******************** TEST (cbe) 'rawdaudio' FAILED! ********************
******************** TEST (cbe) 'encode' FAILED! ********************
******************** TEST (cbe) 'mpeg2decode' FAILED! ********************
******************** TEST (cbe) 'consumer-lame' FAILED! ********************
******************** TEST (cbe) 'consumer-typeset' FAILED!
********************
******************** TEST (cbe) 'office-ispell' FAILED! ********************
******************** TEST (cbe) 'telecomm-fft' FAILED! ********************
******************** TEST (cbe) 'enc-3des' FAILED! ********************
******************** TEST (cbe) 'enc-pc1' FAILED! ********************
******************** TEST (cbe) 'enc-rc4' FAILED! ********************
******************** TEST (cbe) 'tramp3d-v4' FAILED! ********************
******************** TEST (cbe) 'bullet' FAILED! ********************

At this point I'm not sure if its because I'm still missing tools, these
errors are expected on this platform, or there's some problem with my tree.
Any suggestions?

-John

On Thu, Aug 26, 2010 at 7:23 PM, Dale Johannesen <dalej at apple.com> wrote:

>
> On Aug 25, 2010, at 12:45 PM, John Thompson wrote:
>
>  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.
>>
>
> This part is simple, and it can't be worse than it is now.
>
>
>  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.
>>
>
> That's too bad, I didn't know about the AddrModeMatcher reference.  I don't
> see a DAG pointer either; it seems to be an argument in some places.
>  Regardless,  unifying the three loops that do pretty much the same thing is
> surely a good idea.
>
>
>   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 don't have that good a sense of good class design, but this looks OK to
> me.
>
>
>  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.
>>
>
> Those tests don't include any for multiple alternative constraints, since
> the expectation is the llvm-gcc FE will have removed them.  You should
> really run the gcc testsuite as well; that's a much better test of inline
> asm.  If you get this working right there should be some new passes.  I'm
> not sure how to run it using clang as the compiler, but I think Daniel got
> it to work.
>
>
>  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.
>>
>
> I think it's that it's possible to run out of registers if you pick "r" for
> a large number of "rm" constraints.  This mainly affects asm blocks, where
> you have hundreds of lines of asm in a single statement.
>
>
>  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 for working on this.
>
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100830/fa9ed54b/attachment.html>


More information about the llvm-dev mailing list