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

Thu Sep 2 11:12:37 PDT 2010

> Is this something you really want to get in 2.8?

No, it's not.  I'll wait until after 2.8 is safely out.

-John

On Thu, Sep 2, 2010 at 10:55 AM, Dale Johannesen <dalej at apple.com> wrote:

> Actually the 2.8 fork is coming up tomorrow and I'm thinking maybe we
> should wait until after that.  Is this something you really want to get in
> 2.8?
>
>  On Sep 1, 2010, at 6:29 PMPDT, John Thompson wrote:
>
>  Dale,
>
> Thanks.  It's not changed, but I've enclosed a fresh patch against today's
> trunk.
> However, I'm seeing 28 unexpected failing tests in llvm/test on x86 Linux
> 64 today.  But it's the same on an unmodified tree, so I guess I'm still
> okay.  It passed at one point for me with these changes.
>
> -John
> On Wed, Sep 1, 2010 at 5:04 PM, Dale Johannesen <dalej at apple.com> wrote:
>
>>
>>  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
>>
>>
>>
>
>
> --
> 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/20100902/ca3348af/attachment.html>