[LLVMdev] [RFC] CodeGenPrepare will eventually introduce dependencies to libLLVMCodeGen in libLLVMScalarOpts

[Chandler Carruth]

On Wed, Feb 19, 2014 at 1:30 PM, Quentin Colombet <qcolombet at apple.com>wrote:

> Hi,
>
> I am working on a patch for CodeGenPrepare, which introduces a use of
> TargetLoweringBase::InstructionOpcodeToISD (see [1] for the details).
> This is usual for CodeGenPrepare to use the TargetLowering class when it
> is available, however, using this particular function creates linking
> problems.
>
> ** Context **
>
> The TargetLowering class is part of libLLVMCodeGen, which means that in
> theory every consumer of libLLVMScalarOpts would have to link against
> libLLVMCodeGen.
>
> In practice, so far it was not required because all the functions of
> TargetLowering called in CodeGenPrepare are either:
> - virtual function (resolved dynamically).
> - inlined in the header (code available statically).
>
> However, if you use a method that does not follow this pattern (like
> TargetLoweringBase::InstructionOpcodeToISD), the problem will show up.
>
>
> ** Advices Needed **
>
> What would be the right way of fixing that?
>
> There are short term solutions:
> - We can inline the functions we need in the header (Hack).
> - We can mark the functions we need as virtual (Hack).
> - We can move the functions elsewhere (where?).
>

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.


>
> What would be a longer term solution: i.e., how can we prevent this
> problem to happen again?
> The only thing I can think of is moving CodeGenPrepare elsewhere.
>

I think there is a clear way to make this decision:

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.

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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140219/84d9a6cc/attachment.html>