[llvm-commits] [PATCH] Inline asm mult-alt constraint selection - incremental change 2

John Thompson john.thompson.jtsoftware at gmail.com
Mon Oct 11 17:16:48 PDT 2010


Here's an updated patch with some more revisions, adding some missing stuff
I found while developing new tests for the new stuff.  Still lacking is that
I also see that the "lowering" operation is missing support for some of the
x86 constraints I added, which I'll work on next, as well as submitting the
new tests for this stuff.  But may I check in the current changes, so as not
to diverge too much from the trunk?  I've successfully run the regression
tests, test-suite, and the gcc tests with Clang on Linux 64-bit with the
current changes.

-John

On Thu, Oct 7, 2010 at 10:39 AM, John Thompson <
john.thompson.jtsoftware at gmail.com> wrote:

> Here's another incremental patch related to inline asm constraints,
> summarized as follows:
>
> 1. Get more correct reading on the value types.  (See note below.)
> 2. Add remaining generic constraint letter support documented in gcc docs.
> 3. Add remaining X86 constraint letter support documented in gcc docs.
>  4. Convert the weight type to an enum for easier manipulation.
> 5. Change the multi-alternatives array from a vector to a SmallVector.  (I
> might look into changing other vector usages later.)
>
> Regarding 1, there still is some overlap of the value type processing done
> in both TargetLowering::ParseConstraints and
> SelectionDAGBuilder::visitInlineAsm.  I'll address that once I'm sure the
> ParseConstraints stuff is 100% correct.
>
> Regarding 2 and 3 above, this was mainly only for the multiple-alternative
> selection.  There might be additional stuff that some of the constraints
> imply regarding register allocation and instruction selection, but I'm not
> trying to tackle that at this point.  I tried to follow the weighting
> semantics for the non-multiple-alternative constraint selection use
> elsewhere in the SelectionDAG stuff, such as favoring generic registers over
> specific.
>
> I ran the gcc tests on a Linux-64 box, comparing with an unmodified
> version, with no change in test results:
>
> Current gcc tests with clang test run:
>
> # of expected passes        29998
> # of unexpected failures    9887
> # of unexpected successes    29
> # of expected failures        28
> # of unresolved testcases    1450
> # of untested testcases        273
> # of unsupported tests        811
> /home/john/llvm/Release+Asserts/bin/clang  version 2.9 (trunk 115906)
>
> Original:
>
> # of expected passes        29998
> # of unexpected failures    9887
> # of unexpected successes    29
> # of expected failures        28
> # of unresolved testcases    1450
> # of untested testcases        273
> # of unsupported tests        811
> /home/john/llvm_org/Release+Asserts/bin/clang  version 2.9 (trunk 115906)
>
> Diff:
>
> 1c1
> < Test Run By john on Thu Oct  7 00:07:16 2010
> ---
> > Test Run By john on Thu Oct  7 00:52:50 2010
> 42706c42706
> < /home/john/llvm/Release+Asserts/bin/clang  version 2.9 (trunk 115906)
> ---
> > /home/john/llvm_org/Release+Asserts/bin/clang  version 2.9 (trunk 115906)
>
> May I check in this incremental step?
>
> -John
>
> --
> John Thompson
> John.Thompson.JTSoftware at gmail.com
>
>


-- 
John Thompson
John.Thompson.JTSoftware at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20101011/56a43a8f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvmmultalt11.patch
Type: application/octet-stream
Size: 16371 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20101011/56a43a8f/attachment.obj>


More information about the llvm-commits mailing list