Sun, Sep 20
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.
Fri, Sep 18
@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?
Thu, Sep 17
Thanks for the fix!
Wed, Sep 16
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.
Tue, Sep 15
The function should be inlined, in which case there is no performance difference.
Thank you for the patch!
Sun, Sep 13
I was thinking about something that explains the difference between the state before and after the patch.
Fri, Sep 11
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.
Tue, Sep 8
Apply @tskeith's style recommendation
Rebase after D83261
Thanks for catching.
Tue, Sep 1
Yes, abandon in favor of D86551.
Mon, Aug 31
As much as I can say without having a lot of experience with the flang codebase, this looks good to me.
Wed, Aug 26
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.
Mon, Aug 24
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.
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?
Sun, Aug 23
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.
Aug 23 2020
Fix missing helpers
Considering more occurrences in check-expressions.cpp
Aug 22 2020
Reverting to the version without ifdefs
Aug 20 2020
Aug 14 2020
@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)
But are there other workarounds? Would adding "static" to the original "constexpr" suffice to avoid the bug?
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.
Aug 13 2020
Aug 12 2020
Aug 10 2020
- 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.
Aug 9 2020
(I think this code was once copied from clang; clang's CMakeLists.txt now also reuses LLVM's gtest CMakeLists.txt)
The scenario sounds too specific for a single user requiring too much effort to maintain it across build configurations and platforms. Additionally, it makes clang's behavior dependent on the system configuration, which in the past the LLVM community was not in favor of. See http://lists.llvm.org/pipermail/cfe-dev/2016-September/050795.html.
Aug 7 2020
If it is passes that (like Polly) using the in-tree static plugin mechanism, I recommend using the LLVM_<plugin>_LINK_INTO_TOOLS=ON flag.
Aug 6 2020
This also broke the Polly buildbot twice: http://lab.llvm.org:8011/builders/polly-x86_64-linux/builds/3542 and http://lab.llvm.org:8011/builders/polly-x86_64-linux/builds/3547. Please also fix the Polly tests when you get notifications from the Polly buildbot.
Independently on whether it is decided whether these lines are needed at all, I commited D85355. Hence this will need a rebase (which should be trivial: just remove the added lines as well).