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

[David Woodhouse]

On Fri, 2014-01-10 at 15:33 -0800, David Peixotto wrote:
> 
> I've attached the patch that gets rid of the MCSubtargetInfo data member in
> the MCCodeEmitter objects. I do this by adding a MCSubtargetInfo parameter
> to the MCStreamer::EmitInstruction() interface. The subtarget info is then
> threaded down to the MCCodeEmitter::EncodeInstruction() function.

Great, thanks.

> I followed David's lead by storing the MCSubtargetInfo in the
> MCRelaxableFragment and using it to re-encode the instruction when it is
> relaxed. This makes the fragment object larger now because it is storing the
> whole subtarget info object, but it could be made smaller by keeping the
> subtargets const and uniquing them as David suggested.

Yeah, I think that might turn out to be necessary in practice in the
fairly short term, rather than purely as a theoretical thing — there are
a *lot* of relaxable fragments, and adding the STI to each one is going
to account for a fair amount of memory.

An alternative might be to store explicit mode switch fragments instead,
as I outlined in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131216/199633.html but I actually think that putting it in the MCRelaxableFragment and *not* relying on stored state is the better approach.

(And the MCModeSwitchFragment approach I outlined there would need more
work anyway, since it needs an implicit mode switch or reset at the
*start* of the output, or all relaxed instructions up to the first
*explicit* mode switch will be output in the mode that the STI was left
in at the end of the parsing.)

-- 
dwmw2
-------------- 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/20140111/1656ba26/attachment.bin>