[llvm-commits] [llvm] r166595 - /llvm/trunk/tools/opt/opt.cpp

Nadav Rotem nrotem at apple.com
Wed Oct 24 11:25:28 PDT 2012


On Oct 24, 2012, at 11:13 AM, Chandler Carruth <chandlerc at google.com> wrote:

> On Wed, Oct 24, 2012 at 11:05 AM, Nadav Rotem <nrotem at apple.com> wrote:
>> Duncan,
>> 
>> On Oct 24, 2012, at 10:47 AM, Duncan Sands <baldrick at free.fr> wrote:
>> 
>> it's pretty nasty that an IR level tool like opt is now having to
>> initialize asm printers and parsers.  Why is this needed?
>> 
>> 
>> It is not needed.  I removed it.
>> 
>> I thought
>> you had created a limited and tightly controlled interface to provide
>> target cost information, but instead it looks like you are pulling in
>> vast amounts of target stuff...
>> 
>> 
>> We do have a small interface. But the implementation of this interface needs
>> to access TLI. So, we need to link with the codegen.
> 
> The whole point of having an abstract interface was that we could
> provide a stub implementation that does *not* need access to codegen.
> This stub should live inside of VMCore next to the abstract interface,
> and should be what opt uses, avoiding the necessity of linking in or
> initializing all targets.

We have such a stub. It is located in TargetTransformInfo.  TargetTransformInfo is implemented in VMCore. It does not access the codegen.   The TargetTransformImpl is the default codegen implementation which can be overridden by the targets.   Also, the IR-level passes work even when TTI or some of its interfaces are missing. 


> I really think this is the wrong approach. It removes a quite nice
> check that we got the layering separation correct, and all of the
> target information can use interfaces and stub implementation without
> linking in a single backend.

This is incorrect. You can run opt without a triple. In that case the codegen won't be initialized. 

We absolutely need to run IR-level passes that require codegen information. The vectorizer is an example for such a pass. 

> 
> This even breaks some builds because the opt binary doesn't depend on
> enough libraries to allow this and you didn't update the build system.

I updated all of the in-tree build systems.  Which build are failing ?

> 
>> 
>> Thanks,
>> Nadav
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> 




More information about the llvm-commits mailing list