<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 4 February 2014 12:21, Artyom Skrobov <span dir="ltr"><<a href="mailto:Artyom.Skrobov@arm.com" target="_blank">Artyom.Skrobov@arm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">A proper fix for the driver would be to replace the whole cascade of</span><br>
</div>
StringSwitch'es with something tablegen-driven, and ideally based on the<br>
same tablegen files that drive the target selection in the backend. This is<br>
a long-known FIXME, but it's unlikely to be finished in the short-term.<br></blockquote><div><br></div><div>Unfortunately, a "proper fix" was already proposed by many people, and there was enough controversy on that topic for a generation. Furthermore, there are those that don't agree that the driver needs a big change, but rather a small fix, mainly to the architecture definition (CPUs, features, triples, OSs, etc).</div>
<div><br></div><div>AFAICR, the solutions were:</div><div><br></div><div>1. tablegen. PRO: more expressive. CON: static, needs recompilation for small changes</div><div>2. hand-written: PRO: flexible. little changes. CON: will become a mess, again.</div>
<div>3. config files. PRO: dynamic and provider/user driven. CON: different than anyone else is doing, and can become a monster</div><div><br></div><div>The least controversial is 2, so any change in that direction will probably be reviewed quickly. The others, well, good luck. I personally think a mix of hand-written and config files would be the easiest to convince everyone.</div>
<div><br></div><div>cheers,</div><div>--renato</div></div></div></div>