llvm dev - Aug 2010 - [LLVMdev] [REQUEST FOR FEEDBACK] Inline asm multiple alternative constraints

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>

CBE is fairly broken everywhere AFAIK, don't worry about it.
Most of the JIT failures are in tests that exercise exception  
handling.  Not sure if that is supposed to work in your environment,  
it works in some JITs and not others.
The LLC failures are cause for concern.

On Aug 30, 2010, at 10:59 AMPDT, John Thompson wrote:
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100830/bc2237d3/attachment.html>

Dale,

I took a closer look at the first llc failure, initp1.  Looking at the
initp1.llc file in gdb, it appears that the statically constructed objects
without the init_priority attribute are being constructed before those with
it, though the test seems to expect the opposite.

The initp1.llc.s file seems to have the .ctors table in the right order, but
the _init code is reading the table in reverse order.  Since I guess the
init code is coming from the local startup module, this must be a
peculiarity of Linux x86, right?  Is it different on other platforms?
Anyway, it was a good exercise for to see how the tests are run, and and to
dust off my gdb and Linux brain cells.  Is there a prefered platform to run
the test-suite on, where they all pass?  Or is there a test output file I
can compare against?

Thanks.

-John

On Mon, Aug 30, 2010 at 11:10 AM, Dale Johannesen <dalej at apple.com>
wrote:
> CBE is fairly broken everywhere AFAIK, don't worry about it.
> Most of the JIT failures are in tests that exercise exception handling.
>  Not sure if that is supposed to work in your environment, it works in some
> JITs and not others.
> The LLC failures are cause for concern.
>
>    On Aug 30, 2010, at 10:59 AMPDT, John Thompson wrote:
>
>   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
>
> _______________________________________________
> 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/20100830/dd923f84/attachment.html>