[PATCHES] PR18303: Use appropriate Feature flags for encoding instructions

[David Woodhouse]

On Wed, 2014-01-08 at 09:54 -0800, Jim Grosbach wrote:
> 
> Why have this be separate value from what’s in the MCSubtargetInfo?
> Perhaps naively, but I’d have expected to just add a setter method to
> that rather than keeping a separate copy of the data, which can go out
> of sync, in the code emitter itself. If that’s practical, it would
> potentially simplify a lot of things. For example, the isThumb() and
> friends methods won’t need a new argument for the feature bits.

That's kind of the point in the whole thing! :)

The flags in the MCSubtargetInfo *do* get out of sync. In particular,
the AsmParser will toggle them as it encounters .code32/.code64
directives. And the MCCodeEmitter will then immediately output in the
appropriate mode... yay!

However, the problems occur when we a *re*-encoding instructions in
relaxed fragments. We end up encoding them in the mode that the
AsmParser *happened* to leave the MCSubtargetInfo in, at the end of
parsing the file.

Hence storing the *current* feature bits in the MCRelaxableFragment so
when we later re-encode, we can do it in the right mode.

-- 
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/20140108/493d30f1/attachment.bin>