[LLVMdev] [REQUEST FOR FEEDBACK] Inline asm multiple alternative constraints
Dale Johannesen
dalej at apple.com
Wed Sep 1 17:04:12 PDT 2010
On Sep 1, 2010, at 11:03 AMPDT, John Thompson wrote:
> I'm close to confirming that I get the equivalent results from the
> test-suite with my changes, compared to a fresh tree, on a Linux x86
> 64 bit box.
>
> When that is the case, may I check in my current changes for the
> LLVM side?
In principle, yes, I'd like to rereview if it's changed.
> My preference is to develop the mult-alt support incrementally,
> rather than one big check-in, as I get nervous sitting on a lot of
> changes for a long time.
>
> I feel this is relatively safe because the functional change only
> kicks in if the new '|' delimiter is seen in the constraints.
> Otherwise there should be no change in behavior.
I agree.
> -John
> On Mon, Aug 30, 2010 at 3:34 PM, Dale Johannesen <dalej at apple.com>
> wrote:
>
> 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
>
>
>
>
> --
> 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/20100901/52efe243/attachment.html>
More information about the llvm-dev
mailing list