<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 19, 2014 at 1:30 PM, Quentin Colombet <span dir="ltr"><<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi,<div><br></div><div>I am working on a patch for CodeGenPrepare, which introduces a use of TargetLoweringBase::InstructionOpcodeToISD (see [1] for the details).</div>
<div>This is usual for CodeGenPrepare to use the TargetLowering class when it is available, however, using this particular function creates linking problems.</div><div><br></div><div>** Context **</div><div><br></div><div>
The TargetLowering class is part of libLLVMCodeGen, which means that in theory every consumer of libLLVMScalarOpts would have to link against libLLVMCodeGen.</div><div><br></div><div><div>In practice, so far it was not required because all the functions of TargetLowering called in CodeGenPrepare are either:</div>
<div>- virtual function (resolved dynamically).</div><div>- inlined in the header (code available statically).</div></div><div><br></div><div>However, if you use a method that does not follow this pattern (like TargetLoweringBase::InstructionOpcodeToISD), the problem will show up.</div>
<div><br></div><div><br></div><div>** Advices Needed **</div><div><br></div><div>What would be the right way of fixing that?</div><div><br></div><div>There are short term solutions:</div><div>- We can inline the functions we need in the header (Hack).</div>
<div>- We can mark the functions we need as virtual (Hack). </div><div>- We can move the functions elsewhere (where?).</div></div></blockquote><div><br></div><div>None of these will work with many different linking strategies. We need to go after the longer term solution *now* I think. We've waited long enough.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>What would be a longer term solution: i.e., how can we prevent this problem to happen again?</div>
<div>The only thing I can think of is moving CodeGenPrepare elsewhere.</div></div></blockquote></div><br>I think there is a clear way to make this decision:</div><div class="gmail_extra"><br></div><div class="gmail_extra">
Either we want CodeGenPrepare to work *exclusively* through an abstracted interface to the target like TargetTransformInfo like the vectorizer and other "lowering" passes that can easily remain target independent, or we must move CGP into lib/CodeGen.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I think the latter is the obvious answer. I have no reason to think it is remotely plausible to route all of CGP's queries through a narrow abstract interface like TTI. However, we already have quite a few IR-level passes in lib/CodeGen and so sinking CGP there seems like not a bad thing. It solves all of the horrible layering problems that are currently blocking progress and creates no new ones I'm aware of...</div>
</div>