[llvm-commits] Fix an encoding issue with ARM PKH* instructions for non-MC path

[Stephen Hines]

I should be a bit more clear with my answer. The
file test/CodeGen/ARM/pack.ll does contain tests for pkhbt and pkhtb, but
they do not test the actual encoding of the instruction bits. The readable
assembly code is correct, but it is the encoding where the problem shows up.
If there are actual encoding tests for the classic code generation path on
ARM, I would be more than happy to update them. The MC version does
correctly generate the proper encoding (as seen in
test/MC/ARM/simple-encoding.ll).

Steve

On Tue, May 3, 2011 at 6:35 PM, Stephen Hines <srhines at google.com> wrote:

> The MC path is actually fine. This is for the non-MC path which seems to
> not have any tests.
>
> Steve
>
>
> On Tue, May 3, 2011 at 6:34 PM, Bruno Cardoso Lopes <
> bruno.cardoso at gmail.com> wrote:
>
>> Hi Stephen,
>>
>> On Tue, May 3, 2011 at 10:24 PM, Stephen Hines <srhines at google.com>
>> wrote:
>> > Hi,
>> > I am sending this patch because I found that the non-MC ARM path was
>> > incorrectly encoding ARM PKH* instructions. They would essentially be
>> > encoded twice, where the second encoding would unwrap the shift amount
>> in a
>> > way that register fields could be clobbered (by the shift
>> amount/encoding).
>> > I do not have commit privileges, so I would appreciate it if someone
>> could
>> > submit this for me. All current tests pass with this change, since I am
>> > using the non-MC path.
>>
>> Nice! Could you add an encoding test to the patch? See test/MC/ARM for
>> examples.
>>
>> --
>> Bruno Cardoso Lopes
>> http://www.brunocardoso.cc
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110503/bc5b040b/attachment.html>