In D34362#789280, @cmatthews wrote:

It makes more sense to me to be using the --make-param flag to pass a test specific configuration options. If you want to add all these size classes, all the tests should support them, or have them mapped back to nearest size the tests can handle.

In D34362#789152, @MatzeB wrote:

• Indeed, active test-suite development is done in the cmake build (test_suite.py in lnt). You may still change nt.py but landing features exclusively there would be bad.

Thanks for letting me know. Will update for both.

• It seems the llvm test-suite today only checks for SMALL_PROBLEM_SIZE, occasionally LARGE_PROBLEM_SIZE and for SPEC you can choose the size manually. Do you plan to change the test-suite for the new sizes? We should probably do further discussions there.

I added these options only for Polybench. Have not inspected the other benchmarks. I would like to discuss how we can map these sizes for other benchmarks? One we agree upon something, I can make the changes for the test-suite.

• Do you plan to set any rules/expectations on those new sizes? (Something like "mini" finished in half the time than "small")

I have not thought about it yet.

• Out of interest: Why do you need finer control over the problem sizes?

I am working with Polybench, which supports multiple input dataset sizes. I did these changes for my experiments and thought it would be better to upload the changes for the community.

In D34362#788827, @kristof.beyls wrote:

In D34362#788285, @Meinersbur wrote:

I think nt.py is deprecated, and meant to be replaced by test_suite.py.

Maybe someone who already contributed to lnt should be necessary for acceptance.

A few of the most active developers on test-suite and lnt at least think it's better to use the (new) CMake+lit-based system to drive the test-suite rather than the (old) Makefile-based system. 'nt.py' in LNT is a layer around the Makefile-based system, "test_suite.py" is a layer around the CMake+lit-based system. I guess you could say that makes nt.py "deprecated".

Anyway, on the patch itself here: I don't really like adding ever more separate command line options for specifying different data sizes available in a test suite. Wouldn't it be better to introduce a command line argument spelled e.g. "--datasize=mini|small|standard|large|extra_large"? We could then also hopefully deprecate "--small", "--large", "--spec-with-ref", etc., making them aliases for the new command line option for backwards compatibility. Note that I haven't thought about what the best name would be for this option. Maybe "inputsize" is more in line with common terminology across benchmarks? Although it may be hard to guess from the "inputsize" exactly what it means without further explanation either...

I agree with you. I was planning to add such a flag for all the sizes "--datasize=mini|small|standard|large|extra_large". Did not do it for compatibility. Thanks for the suggestion about aliasing for backward compatibility. If we agree on adding such an option, I think "--testdatasize" will be appropriate. And I would argue about using a common flag like this one for all for all data sizes instead of using "--make-param" flag as pointed out by @cmatthews.

In D34362#788285, @Meinersbur wrote:

I think nt.py is deprecated, and meant to be replaced by test_suite.py.

Maybe someone who already contributed to lnt should be necessary for acceptance.

Updated as per review comments.

I tested this with lnt and there are no crashes. However, there exists few failed cases with and without this patch.

Updated according to review comments.

Updated the patch with necessary changes. Added unit test cases.

Fixed corrupt memory issues due to isl objects. Added test cases.

Thanks a lot. I will experiment with it.
Created a new pass to calculate dependences for a function D21105.
We can introduce similar changes over their.

Please review and comment.

Thank you for your inputs. I have updated the patch accordingly.
Please let me know if this set of test cases is not enough.

Follow variable naming convention.
Delete ScopBuilder after new in ScopInfoRegionPass::runOnRegion.

Rebased over patch D20831 which is not committed yet.

This patch only renames ScopInfo class to ScopBuilder. This change is required because ScopBuilder class only creates SCoP objects, it is not a container class to store them. Valid SCoP objects will be contained in ScopInfoRegionPass and ScopInfoWrapperPass.

Separated renaming of ScopInfo to ScoBuilder and adding a new pass ScopInfoWrapper pass into two patches.

Hello Tobias,

• Removed releaseMemory and print functions from ScopInfo class as they are not required any more.

I have done the changes you requested. Have arc for the new patch.

• Decouple Scop building logic from pass logic
• Removed createScopInfo function and inlined code into ScopInfo constructor.

Filter UnDef size values in Scop Detection.

Yes I saw that now. Thanks for catching it so quickly. Now all the test cases are passing.

Hi Tobias,

In D11425#210032, @grosser wrote:

Hi Utpal,

thanks for your work.

The patch itself looks good, but could you please include a test case in