[llvm-commits] [PATCH, PowerPC] Fix MC instruction encodings

Ulrich Weigand Ulrich.Weigand at de.ibm.com
Tue Nov 13 12:25:14 PST 2012


Chandler Carruth <chandlerc at google.com> wrote on 13.11.2012 21:08:11:
> On Tue, Nov 13, 2012 at 11:23 AM, Ulrich Weigand
> <Ulrich.Weigand at de.ibm.com> wrote:
> > Hal Finkel <hfinkel at anl.gov> wrote on 13.11.2012 20:01:08:
> >
> >> LGTM. We should add test cases (but I think that we can't do that
> >> until we have the asm parser working, and that's blocked by TableGen
> >> problems), so those can wait.
> >
> > Checked in as revisions 167860..167863.
> >
> > Agree on the test cases ...
>
> FWIW, I don't think this is a good strategy. It is *essential* that we
> prioritize all of the efforts necessary to fix the underlying
> infrastructure first, so that we can build up a proper regression test
> suite each time these types of encoding fixes go into the tree.
>
> I would ask that folks who care about PPC focus their efforts on
> resolving these underlying issues first, and then come back to
> encoding bugs.

I agree that we urgently need to get the asm parser working, and
then create a full set of test cases for instruction encodings.
We're working on it ...

However, right now, there is *no* test whatsoever for any encoding,
so IMHO it doesn't really make sense to block patches that fix
obviously broken encodings until the infrastructure is in place.

As to the testing I did:  I built all of test-suite twice, once
using clang set to use the integrated assembler, and once using
clang set to use the system assembler, and then compared all the
resulting object files.

With the set of patches just applied, I'm getting 100% identical
.text sections between integrated and system assembler, for all
those object files.

While this is obviously not automated, I'm planning to regularly
re-run such tests until we have the asm parser and and encoding
test suite in place, to ensure we don't regress.

Bye,
Ulrich




More information about the llvm-commits mailing list