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

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>

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

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