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

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?

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.
-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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100901/d9678e56/attachment.html>

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>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100901/b6fcec4b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvmmultalt7.patch
Type: application/octet-stream
Size: 29572 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100901/b6fcec4b/attachment.obj>