Should there be some documentation about the new attribute?

I think the document is more useful as a reference than a text-book reading.

• Address further comments by @baxiotis

What do you think of the revision? Does it clarify things? Is it more understandable?

• Address @baziotis comments
• Lines breaks
• Further fixes
• Undefined when not reachable

There are different definitions of loops. In the literature, such as a Dragon Book, a loop is identified by a backedge, but LLVM does it with its header. But only natural loops have a header: that is, not all cyclic control flow is represented by LoopInfo. Cyclic control flow that is is not form a natural loop is called irreducible control flow.

Just avoiding the template is sufficient.

Microsoft bug report: https://developercommunity.visualstudio.com/content/problem/1193950/ambiguous-constructor-in-vector-copy.html

Thank you

Visual Studio bug report: https://developercommunity.visualstudio.com/content/problem/1192775/ambiguous-constnon-const-method-call-in-implicit-t.html

Thank you

A single test test file would be enough to check that the new pass manager pipeline is working. Checking all tests with both pass manager doubles the execution time for check-polly without improving test coverage. There are not too many tests for the simplify pass, but please consider testing it only once with the scalability tests, as these take the most time.

@baziotis Are you going to update this diff?

Could you add a test that invokes the pass with the new pass manage? E.g. take an existing test for the SimplifyPass, and add a RUN: line that does the same thing with NPM?

Thanks for the fix!

Thank you.

Why is this specific to the PowerPC-backend. Doesn't the LoopUnrollAndJamPass pick-up the transformation metadata already?

Do you have a suggestion for a large Fortran file that I could measure? I think my measurements would not be accurate enough to show a difference between inlining and non-inlining of this function. If you know how to do it yourself, I would be grateful.

The function should be inlined, in which case there is no performance difference.

Microsoft bug report: https://developercommunity.visualstudio.com/content/problem/1185857/if-constexpr-false-body-evaluated-in-variadic-temp.html

Thank you for the patch!

I was thinking about something that explains the difference between the state before and after the patch.

Could you fix the title+description? It fixes that the limitation is imposed by Windows, not by the MSVC compiler. Cygwin would be affected as well.

Apply @tskeith's style recommendation

Rebase after D83261

Thanks for catching.

Yes, abandon in favor of D86551.

As much as I can say without having a lot of experience with the flang codebase, this looks good to me.

In D85627#2226214, @ro wrote:

In D85627#2206550, @Meinersbur wrote:

What do you mean by intended solution? My intent was to avoid breaking the build with PIC code turned off. Just as Windows doesn't support loadable modules and thus creation of LLVMPolly.so is disabled, it's just not possible to build a loadable module/shared object without PIC code, so there's no choice but to disable it.

According to CODE_OWNERS.TXT, that @sscalpone

I can confirm that shape.cpp compiles with your patch.

I am not familiar with TypeParameterInquiry. Since this solution works, a restructure might not be necessary unless you plan to do the change anyway.

Use explicit method specializations in base class.

In D86410#2233901, @klausler wrote:

Is the MSVC bug peculiar to template member functions like template <int K> operator()(const TypeParamInquiry<K> &) const? If so, is it peculiar to *just* TypeParamInquiry, or does it affect other templatized expression nodes as well?

What is your alternative suggestion to fix the compiler error?

Bug was was already reported (but no yet fixed) at https://developercommunity.visualstudio.com/content/problem/1067774/ice-internal-compiler-error-on-constexpr-range-bas.html.

Fix missing helpers

Bug report: https://developercommunity.visualstudio.com/content/problem/1159566/ambiguous-call-to-template-method-from-using-decla.html

Considering more occurrences in check-expressions.cpp

Reverting to the version without ifdefs

@klausler I updated the patch before I noticed you accepted the version without the requested change that you defended vigorously. Which version do you want?

• Make workaround conditional to msvc (requested by @klausler)

In D85937#2219266, @klausler wrote:

But are there other workarounds? Would adding "static" to the original "constexpr" suffice to avoid the bug?

In D85937#2219028, @klausler wrote:

You might have to use conditional preprocessing to make this workaround specific to MSVC.

Add missed constexpr

The pre-merge check

clang-tidy: warning: variable 'digitString64' defined in a header file; variable definitions in header files can lead to ODR violations [misc-definitions-in-headers]

is correct: I forgot the constexpr for the variable declaration here. Going to update the patch.

Reported here: https://developercommunity.visualstudio.com/content/problem/1151042/class-with-constexpr-constructor-and-variable-declaration-in-same-declarator.html

• Use llvm::report_fatal_error

Could you outline your intended solution? If I read correctly, with LLVM_ENABLE_PIC=OFF, no Polly module will be built, making Polly useless unless Polly is built in-tree and LLVM_POLLY_LINK_INTO_TOOLS is used.