- User Since
- Jun 17 2015, 7:07 AM (275 w, 5 d)
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
Thu, Sep 24
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.
Wed, Sep 23
Just avoiding the template is sufficient.
Tue, Sep 22
Mon, Sep 21
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.
Aug 26 2020
Aug 24 2020
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.
What is your alternative suggestion to fix the compiler error?
Aug 23 2020
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
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)
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.