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

[David Woodhouse]

On Wed, 2014-01-15 at 14:38 -0800, David Peixotto wrote:
> I think it moves in a good direction. At least we are explicit now about 
> the required sharing of the SubtargetInfo state between the parser and 
> encoder.

Right.

> > I'd like to see this go in, and then perhaps we can follow up afterwards
> > with reducing the memory usage by uniquifying the SubtargetInfo and
> > storing only a reference in the MCRelaxableFragment...?
> 
> As you said the size issue might be a problem. It looks like there is a 
> new RelaxableFragment for each instruction that could be relaxed. I 
> think the uniqing idea would help, but then that is another potential 
> api change (if we make subtargetinfo truly const).

That doesn't have to be a very complex change, really. I imagine it
could start with a method on the existing SubtargetInfo which returns a
const version of itself with the *current* settings.

That 'const version' probably wants to be a parent class, I suppose, and
wants to be what gets stored in the MCRelaxableFragment and passed to
the MCStreamer.

> Yes, it is going to quickly become outdated and will need attention 
> until it is actually merged. My other question is whether we should 
> commit it all at once as a big monolithic change or do it smaller 
> bit-by-bit commits.

I think the way you split it was about right. It might be vaguely
possible to split the first patch into more separate commits, perhaps
adding an *unused* STI argument to getBinaryCodeForInstr() and then
making it *use* that argument in a separate patch. But I don't think
that's particularly useful.

-- 
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/20140116/69a4f56a/attachment.bin>