[PATCH v3 12/11] Fix incorrect encoding of relaxed instructions (PR18303)

[David Woodhouse]

On Mon, 2014-01-06 at 12:24 -0800, Jim Grosbach wrote:
> I like, in general, the approach of attaching the feature bits to a
> fragment rather than the instruction itself, which seems like
> significant overkill since they will almost always (especially for
> compiler generated code) all be the same.
> 
> -Jim
> 
> cc greg and david since they’re looking at some (semi) related issues
> in the ARM backend.

Looking back in the archives, I think the issue they were looking at is
somewhat different. They were worried about inline asm changing the mode
— something I wouldn't have worried about myself. In GCC, inline asm is
*supposed* to take permanent effect (hence asm(".code16gcc") working).

If you can emit asm, then you can break the result of compilation. Film
at 11. Consider asm("ha ha bonk!"). I don't think we really need to
guard against that. You do kind of need to know what architecture (and
mode) you're targeting before you emit inline asm!

That said, a mode-equivalent of ".previous" could be a useful feature
addition.

For the problem I'm looking at, here's the test case for ARM:

// RUN: llvm-mc -filetype=obj -triple thumbv7-linux-gnu %s -o %t
// RUN: llvm-objdump -triple thumbv7-linux-gnu -d %t | FileCheck %s

//PR18303
.code 16
.global edata
b edata // CHECK: b.w
.code 32


Remove the '.code32' at the end and watch it stop failing...

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140107/5a8823a9/attachment.bin>