[PATCH][AArch64] Add llvm-mc test for asm code generated from all LLVM IR tests

[Jiangning Liu]

Hi Ana,

Sometimes the pattern match could be incorrect and finally compiler
generates incorrect assembly code. This procedure only goes though
disassembling stage in MCLayer, and it doesn't go though asm parser stage
at all. So it's possible we generate some invalid assembly code due to
incorrect patterns with loose constraint.

With this test applied, we would be able to go though asm parser and
encoding stages, and the only missing part is decoding stage, but I think
it can be accepted. As I mentioned in the last sentence of my early email
in this thread, a bug was found using this test, and Hao delivered a patch
and get it fixed at
http://llvm.org/viewvc/llvm-project?view=revision&revision=195941.

Thanks,
-Jiangning


2013/12/3 Ana Pazos <apazos at codeaurora.org>

> Hi Jiangning,
>
>
>
> With this scheme you would still be testing the MC layer encoding against
> the MC layer decoding, right?
>
> You cannot guarantee your MC layer encoding and decoding are correct in
> this way, since you are testing against MC layer itself.
>
> Probably this is the reason it is discouraged in CodeGen tests.
>
>
>
> Ana.
>
>
>
> *From:* llvm-commits-bounces at cs.uiuc.edu [mailto:
> llvm-commits-bounces at cs.uiuc.edu] *On Behalf Of *Jiangning Liu
> *Sent:* Sunday, December 01, 2013 7:54 PM
> *To:* Jim Grosbach
> *Cc:* llvm-commits at cs.uiuc.edu for LLVM
> *Subject:* Re: [PATCH][AArch64] Add llvm-mc test for asm code generated
> from all LLVM IR tests
>
>
>
> Jim,
>
>
>
> I'm not fully convinced by Tim's explanation yet, so could you please
> provide more explanation?
>
>
>
> The key point of this improvement is to enlarge the testing coverage. We
> don't really have a mechanism to check if all of the code generated in
> CodeGen can pass MClayer yet.
>
>
>
> It would be also OK if we can provide a general mechanism to ask the asm
> result generated by llc in CodeGen to pass MC test.
>
>
>
> This is kind of test can obviously expose some bugs, and those bugs could
> be caused by either incorrect pattern match of pattern match with loose
> constraint.
>
>
>
> I think it is not always easy to cover all of the scenarios in MCLayer
> test, and particularly it's hard to cover every corner of negative test
> scenarios. Enlarging testing coverage should be helpful to build a robust
> compiler infrastructure, right?
>
>
>
> As I mentioned above, we did find bugs using this test. Also, this kind of
> test should be very fast, and I don't think it would
> increase regression test time.
>
>
>
> Looking forward to your response!
>
>
>
> Thanks,
>
> -Jiangning
>
>
>
>
>
>
>
>
>
> 2013/11/28 Tim Northover <t.p.northover at gmail.com>
>
> Hi Jiangning,
>
> I think this might be a layering violation (I've CCed Jim Grosbach,
> who's pretty much the authority). I know that object file tests are
> discouraged from CodeGen, and this seems very similar.
>
> I think the preferred option would be to make sure any test you
> believe it's usefully doing is part of the test/MC hierarchy.
>
> Cheers.
>
> Tim.
>
>
>
>
>
> --
>
> Thanks,
>
> -Jiangning
>



-- 
Thanks,
-Jiangning
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131203/359671ab/attachment.html>