| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
Scops that only read seem generally uninteresting and scops that only write are
most likely initializations where there is also little to optimize. To not
waste compile time we bail early.
Differential Revision: http://reviews.llvm.org/D7735
llvm-svn: 229820
|
|
|
|
|
|
| |
Thanks Albert Cohen.
llvm-svn: 224584
|
|
|
|
|
|
|
|
| |
SCEV based code generation has been the default for two weeks after having
been tested for a long time. We now drop the support the non-scev-based code
generation.
llvm-svn: 222978
|
|
|
|
|
|
|
|
|
| |
This commit drops a call to std::sort, which sorted the base pointers that
possibly alias according to the address at which their corresponding llvm::Value
was allocated. There does not seem to be any good reason, why those pointers
should be (re)sorted and this only makes the output indeterministic.
llvm-svn: 218052
|
|
|
|
|
|
|
|
|
|
| |
At the moment we assume that only elements of identical size are stored/loaded
to a certain base pointer. This patch adds logic to the scop detection to verify
this.
Differential Revision: http://reviews.llvm.org/D5329
llvm-svn: 217727
|
|
|
|
| |
llvm-svn: 215832
|
|
|
|
| |
llvm-svn: 215831
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will spill out information about LLVM-internals. However, in cases
where the name of the Value matches the name of the array in the source,
we provide more useful information. In cases where we spill internals,
the information still might help the user to pin down the correct
arrays.
The problem we face here is: The error is pinned to the debug location
of one of the offending values out of the alias set instead of all of them.
The more information we give the user about the set of aliasing
pointers the better.
llvm-svn: 215830
|
|
|
|
| |
llvm-svn: 215627
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Store the llvm::Value pointers of the AliasSet instead of the AliasSet
itself.
We have to be careful about changed IR when the message is generated,
because the Value pointers might not exist anymore. This would render
the Diagnostic invalid. For now we just assert there.
Simply do not retreive a diagnostic message after the IR has changed
it's not valid information anyway.
llvm-svn: 215625
|
|
|
|
| |
llvm-svn: 215623
|
|
|
|
| |
llvm-svn: 211777
|
|
|
|
| |
llvm-svn: 211773
|
|
|
|
| |
llvm-svn: 211770
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for generating optimization remarks after completing the
detection of Scops.
The goal is to provide end-users with useful hints about opportunities that
help to increase the size of the detected Scops in their code.
By default the remark is unspecified and the debug location is empty. Future
patches have to expand on the messages generated.
This patch brings a simple test case for ReportFuncCall to demonstrate the
feature.
Reports all missed opportunities to increase the size/number of valid
Scops:
clang <...> -Rpass-missed="polly-detect" <...>
opt <...> -pass-remarks-missed="polly-detect" <...>
Reports beginning and end of all valid Scops:
clang <...> -Rpass="polly-detect" <...>
opt <...> -pass-remarks="polly-detect" <...>
Differential Revision: http://reviews.llvm.org/D4171
llvm-svn: 211769
|
|
|
|
| |
llvm-svn: 210752
|
|
We don't want the Statistic variables in every module that
includes the diagnostics.
llvm-svn: 209571
|