[PATCH] Allow opt to run pass that needs target machine.

Andrew Trick atrick at apple.com
Thu Jan 16 11:17:35 PST 2014


On Jan 16, 2014, at 11:14 AM, Quentin Colombet <qcolombet at apple.com> wrote:

> Hi Andy,
> 
> Thanks for the feedbacks.
> Here is the updated patch that makes a special initialization for CodeGenPrepare.

LGTM. Thanks.
-Andy

> 
> Cheers,
> -Quentin
> <codegenprepare-test.patch>
> 
> On Jan 15, 2014, at 1:43 PM, Andrew Trick <atrick at apple.com> wrote:
> 
>> 
>> On Jan 15, 2014, at 12:18 PM, Quentin Colombet <qcolombet at apple.com> wrote:
>> 
>>> Hi,
>>> 
>>> The attached patch adds the machinery into opt to enable testing passes that use target machine information.
>>> Thanks for your review.
>>> 
>>> ** Context **
>>> 
>>> opt is a great tool to test/play with IR to IR passes. However, opt is not able to feed a pass with target machine information (like TargetLowering) and this prevents the testing (or an easy testing) of the meaty part of some passes (e.g., codegenprepare). 
>>> 
>>> 
>>> ** Proposed Solution **
>>> 
>>> When registering a pass, a pass can now specify a second construct that takes as argument a pointer to TargetMachine.
>>> The PassInfo class has been updated to reflect that possibility.
>>> If such a constructor exists opt will use it instead of the default constructor when instantiating the pass.
>>> 
>>> A pass can specify that it supports the second constructor by using the new INITIALIZE_PASSxxx_WITH_TM as illustrated in codegenprepare.
>>> 
>>> A subsequent patch will make use of this feature to better test codegenprepare on something I am currently working.
>> 
>> I agree, we need to be able to test codegenprepare. We don’t want to expose this interface to other passes though. IR passes should go through TTI instead.
>> 
>> Hardcoding a check for codegenprepare within opt.cpp isn’t great either. As we discussed in person, a good compromise would be to directly call setTargetMachineCtor from CodeGenPrepare so we don’t need the INITIALIZE_PASS…WITH_TM macros.
>> 
>> -Andy
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140116/55dff3de/attachment.html>


More information about the llvm-commits mailing list