[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