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

Dale Johannesen dalej at apple.com
Mon Aug 30 15:34:47 PDT 2010


On Aug 30, 2010, at 3:11 PMPDT, John Thompson wrote:

> 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?

I don't know, you'll have to get help from somebody who uses Linux.

> 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?

llvm changes very quickly and at any given moment some tests might be  
broken on some platforms.  Regressions are usually fixed quickly,  
though.  Darwin x86-{32/64} gets the most attention.

>  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
>
> _______________________________________________
> 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/09eaf0fd/attachment.html>


More information about the llvm-dev mailing list