[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