<div dir="ltr">This patch still has the placement new thing I was initially concerned about, but if it isn't worth holding up progress for, that's fine.<div><br></div><div><div>Dan</div></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Jun 26, 2013 at 11:42 AM, Bill Wendling <span dir="ltr"><<a href="mailto:wendling@apple.com" target="_blank">wendling@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So...ping?<br>
<br>
Anyone else have a problems with or comments on the patch? (Other than the cleanup that Stefanus mentioned.)<br>
<span class="HOEnZb"><font color="#888888"><br>
-bw<br>
<br>
</font></span><br><br>
<br>
On Jun 21, 2013, at 11:14 AM, Bill Wendling <<a href="mailto:wendling@apple.com">wendling@apple.com</a>> wrote:<br>
<br>
> On Jun 20, 2013, at 6:48 AM, "Du Toit, Stefanus" <<a href="mailto:stefanus.du.toit@intel.com">stefanus.du.toit@intel.com</a>> wrote:<br>
><br>
>> Hi Bill,<br>
>><br>
>> From:  Bill Wendling <<a href="mailto:wendling@apple.com">wendling@apple.com</a>><br>
>>> For those not interested in slugging their way through a ton of<br>
>>> refactoring code, here's a cleaner patch.<br>
>>><br>
>>> The executive summary:<br>
>>><br>
>>> This regenerates the TargetMachine object if the any of the values in<br>
>>> TargetOptions changes. The regeneration is recursive, because creating<br>
>>> TargetMachine pretty much creates all of the other back-end objects that<br>
>>> are needed for code generation.<br>
>><br>
>> You could use the "curiously recurring template pattern" and add an<br>
>> instance of a class template in the middle of the inheritance hierarchy,<br>
>> e.g. something alone the lines of:<br>
>><br>
>> template<typename Derived><br>
>> class TargetMachineHelper : public TargetMachine {<br>
>> TargetMachine *<br>
>> regenerateWithOptionsImpl(const TargetOptions &Opts,<br>
>>                           Reloc::Model RM,<br>
>>                           CodeModel::Model CM,<br>
>>                           CodeGenOpt::Level OptLvl,<br>
>>                           std::string &targetTriple,<br>
>>                           std::string &targetCPU,<br>
>>                           std::string &targetFS) {<br>
>>   TargetPassConfig *TPC = PassConfig;<br>
>><br>
>>   this->~Derived();<br>
>>   Derived *NewTM = new (this)<br>
>>     Derived(TheTarget, targetTriple, targetCPU, targetFS,<br>
>>             Opts, RM, CM, OptLvl);<br>
>><br>
>>   if (TPC)<br>
>>     NewTM->PassConfig = TPC->regenerateWithTargetMachine(NewTM);<br>
>><br>
>>   return NewTM;<br>
>> }<br>
>> };<br>
>><br>
>> // Then, for each backend, change the inheritance like so:<br>
>><br>
>> class MyTargetMachine : public TargetMachineHelper<MyTargetMachine> {<br>
>> // ...<br>
>><br>
>> (I'm sure there are errors in the above, but hopefully it gets the idea<br>
>> across)<br>
>><br>
>> This would remove the need to define all of these similar-looking<br>
>> functions in the backends. Should work for PassConfig too.<br>
>><br>
> Not a bad idea. I'll look into it. Thanks!<br>
><br>
> -bw<br>
><br>
> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>