In case we are at the innermost band, we try to prepare for vectorization. This
means, we look for the innermost parallel loop and strip mine this loop to the
innermost level using a strip-mine factor corresponding to the number of vector
iterations.
For whatever reason, the code that implemented this feature was broken. We now
added a comment, a test case and obviously also the right code.
llvm-svn: 203544
1) The isl_int -> isl_val changes are the ones Tobias suggested.
One additional isl_val_free is added (and needed)
2) Three scoplib_vector_free are added, maybe we would need even
more (and matrix_free) but it's hard to place them right.
3) Cleaned the includes (and removed 'extern C')
This fixes the broken compilation for the scoplib import and export.
Contributed-by: Johannes Doerfert <doerfert@cs.uni-saarland.de>
llvm-svn: 203500
to avoid build errors like this:
In file included from ../include/llvm/IR/IntrinsicInst.h:30:0,
from ../tools/polly/lib/CodeGen/BlockGenerators.cpp:28:
../include/llvm/IR/Intrinsics.h:41:34: fatal error: llvm/IR/Intrinsics.gen: No such file or directory
llvm-svn: 203495
Value::user_iterator changes in LLVM r203364. Converts several of these
loops to nice range based loops in the process.
Built and tested cleanly for me, yay for being able to fully build and
test Polly changes!
llvm-svn: 203381
For now we only mark innermost loops for the loop vectorizer. We could later
also mark not-innermost loops to enable the introduction of openmp parallelism.
llvm-svn: 202854
PollyIRBuilder is currently just a typedef to IRBuilder<>. Consequently, this
change should not affect behavior. In subsequent patches we will extend its
functionality to emit loop.parallel metadata.
llvm-svn: 202853
This fixes the buildbots who failed, because the linker eliminated most of the
Polly functionality when building without BUILD_SHARED_LIBS=ON.
Besides fixing the build, this change also brings additional functionality. With
the new separation between the general polly libraries and the functionality for
the polly module, it is now possible to link polly directly into a tool instead
of using requiring users to load a shared library.
llvm-svn: 202762
The module LLVMPolly.so links to that. There is really no reason to build a
large number of mini-libraries here, especially as we do have dependences
between the libraries that are not properly handled and that make linking fail
on darwin.
Submitted-by: David Fang <fang@csl.cornell.edu>
llvm-svn: 202743
We mostly iterate over read-only values. Following a suggestion by Duncan P.N
Exons Smith, we use the construct 'const auto &' for this.
llvm-svn: 202651
clang-formats behaviour has changed for a couple of C++11 formattings. We adapt
Polly to ensure our formatting checks are clean again.
llvm-svn: 202650
clang-format requires a space before the ":" in the foreach loop. Even though
this is surprising to me, we follow this style to make our formatting
consistent with clang-format. I found that this clang-format style is used in a
couple of C++11 examples, hence I believe the fact that clang-format adds a
colon is not a bug but just something I was not used to yet.
llvm-svn: 202648
In 'obsequi' we have a scop in which the current dead code elimination works,
but the generated code is way too complex. To avoid this trouble (and to not
disable the DCE entirely) we add an additional approximative step before
the actual dead code elimination. This should fix one of the two current
nightly-test issues.
Polly could be improved to handle 'obsequi' by teaching it to introduce only a
single parameter for (%1 and zext %1) which halves the number of parameters and
allows polly to derive a simpler representation for the set of live iterations.
However, this needs some time to investigate.
I will commit a test case as soon as we have a reduced one.
llvm-svn: 202010
Sven suggested to use this simpler code generation strategy as the convex_hull
computation is apparently rather inefficient. We do not have a test case that
shows a difference, but, in case we find a test case where this makes a
difference, we can reconsider our decission.
llvm-svn: 201997
In case we do not have valid dependences, we do not run dead code elimination or
the schedule optimizer. This fixes an infinite loop in the dead code
elimination (PR12110).
llvm-svn: 201982
Instead of giving a choice between a precise (but possibly very complex)
analysis and an approximative analysis we now use a hybrid approach which uses N
precise steps followed by one approximating step. The precision of the analysis
can be changed by increasing N. With a default of 'N' = 2, we get fully precise
results for our current test cases and should not run into performance problems
for more complex test cases. We can adjust this value when we got more
experience with this dead code elimination.
llvm-svn: 201888
In case the domain of a statement is empty, the schedule optimizer set by
accident the schedule to a NULL pointer. This is incorrect. Instead, we set
it to an empty isl_map with zero schedule dimensions. We already checked for
this in our test cases, but unfortunately the test cases did not fail as
expected. The assert we add in this commit now ensures that the test cases
fail properly in case we regress on this again.
llvm-svn: 201886
We now skip the debug intrinsics which is a lot better than crashing due to
uncopied metadata references. We should step by step investigate which debug
intrinsics we can copy without trouble.
We still keep the debug location metadata.
llvm-svn: 201860
This pass eliminates loop iterations that compute results that are not used
later on. This can help e.g. in D, where the default zero-initialization is
often unnecessary if right after new values are assigned to an array.
Contributed-by: Peter Conn <conn.peter@gmail.com>
llvm-svn: 201817
We do not have a use for this information at the moment. If we need this at some
point, the "instruction -> access" mapping needs to be enhanced as a single
instruction could then possibly perform multiple accesses.
This patch allows us to build the polyhedral information for scops with scalar
dependences.
llvm-svn: 201815
In rare cases the modification of one scop can effect the validity of other
scops, as code generation of an earlier scop may make the scalar evolution
functions derived for later scops less precise. The example that triggered this
patch was a scop that contained an 'or' expression as follows:
%add13710 = or i32 %j.19, 1
--> {(1 + (4 * %l)),+,2}<nsw><%for.body81>
Scev could only analyze the 'or' as it knew %j.19 is a multiple of 2. This
information was not available after the first scop was code generated (or
independent-blocks was run on it) and SCEV could not derive a precise SCEV
expression any more. This means we could not any more code generate this SCoP.
My current understanding is that there is always the risk that an earlier code
generation change invalidates later scops. As the example we have seen here is
difficult to avoid, we use this occasion to guard us against all such
invalidations.
This patch "solves" this issue by verifying right before we start working on
a detected scop, if this scop is in fact still valid. This adds a certain
overhead. However the verification we run is anyways very fast and secondly
it is only run on detected scops. So the overhead should not be very large. As
a later optimization we could detect scops only on demand, such that we need
to run scop-detections always only a single time.
This should fix the single last failure in the LLVM test-suite for the new
scev-based code generation.
llvm-svn: 201593
The MayAliasSet class is currently not used and just confuses people. We can
reintroduce it in case need a more precise tracking of alias sets.
llvm-svn: 201191
There does not seem to be a reason that we can not support PHI nodes outside of
the scop that reference values within the SCoP. Or at least, the attached test
case seems to do the right thing. We remove the assert for now.
llvm-svn: 200427
In rare cases, a region R which is itself not valid has an indirect child region
that is valid. When R becomes part of a valid region by expansion of another
region, then all children of R have to be erased from the set of valid regions.
This patch ensures that indirect children are erased in addition to direct
children.
Contributed-by: Armin Groesslinger <armin.groesslinger@uni-passau.de>
Tobias: I added a reduced test case and adjusted the logic of the patch to
only recurse until the first child is found.
llvm-svn: 200411
Verification of base addresses is difficult as the independent blocks pass may
introduce aliasing that was not there during scop detection. As a midterm
solution -polly-codegen-scev will remove the need for the independent blocks
pass. For now, we do not verify at compile time that the independent blocks pass
does not make the base addresses loop invariant. Disabling this just removes
one of the multiple safety layers we have. We still can check for correctness
in our regression tests.
llvm-svn: 200315
Array base addresses need to be invariant in the region considered. The base
address has to be computed outside the region, or, when it is computed inside,
the value must not change with the iterations of the loops. For example, when a
two-dimensional array is represented as a pointer to pointers the base address
A[i] in an access A[i][j] changes with i; therefore, such regions have to be
rejected.
Contributed by: Armin Größlinger <armin.groesslinger@uni-passau.de>
llvm-svn: 200314
Restricting Polly to -O3 does not make a lot of sense as it is opt-in anyway
and users who specifically request it should get it. If this causes performance
problems we should rather address them by scheduling the right cleanup passes
then just prevent the user from trying.
Also restricting Polly to -O3 made bugpoint not work with the -O3 flag and polly
enabled.
llvm-svn: 200208
Count the number of computational steps that have been used to solve the
dependence problem and abort in case we reach the "compute-out". This ensures we
do not hang forever in cases the dependence problem is too difficult to solve.
There is just a single case in the LLVM test-suite that runs into the
compute-out. Even in this case, we can probably coalesce some of the parameters
(i32 b, i32 b zext i64, ...) to simplify the problem enough to not hit the
compute out. However, for now we set the compute out in place to address the
general issue. The compute out was choosen such that it stops on a recent laptop
after about 8 seconds.
llvm-svn: 200156
This includes the following very useful isl commit:
commit d962967ab42323ea5ca0398956fbff6a98c782fa
Author: Sven Verdoolaege <skimo@kotnet.org>
Date: Wed Dec 18 12:05:32 2013 +0100
allow the user to impose a bound on the number of low-level operations
This should allow the user to deterministically limit the effort spent on a
computation.
llvm-svn: 200155
This removes the last isl_int dependency in the default build. There are
still some in OpenScop and Scoplib. For those isl-0.12.2 still needs to be used.
llvm-svn: 199585
This ModulePass schedules the set of Polly canonicalization passes. It is a
debugging tool that can be used to preoptimize .ll files for Polly processing.
llvm-svn: 198376
Also the code makes the impression this was happening, shouldEnablePolly()
always returns false for optlevel equal to zero. This was previously different,
but was accidentally changed by a commit a couple of months ago. As this
behavior was mainly a debugging tool and adding this to clang never really made
sense, we just remove the last traces.
llvm-svn: 198370
This fixes a crash that appeared when generating dotty graphs for functions
without loops (for which we do not calculate polyhedral information).
llvm-svn: 198364
We now report the following:
$ polly-clang -O3 -mllvm -polly -mllvm -polly-report test.c -c \
-gline-tables-only
note: Polly detected an optimizable loop region (scop) in function 'foo'
test.c:2: Start of scop
test.c:3: End of scop
note: Polly detected an optimizable loop region (scop) in function 'bar'
test.c:9: Start of scop
test.c:13: End of scop
llvm-svn: 197558
For for-nodes that are translated to a set of vector lanes, we already know the
overall number of iterations. Calculating the upper bound is consequently not
necessary. This change removes the code for upper bound calculation, which was
probably copy/pasted from the code generation for the normal for-loop.
This issue was found by Sylvestre's scan-build server.
llvm-svn: 193925
When constructing a scop sometimes the exact representation of a statement or
condition would be very complex, but there is a common case which is a lot
simpler, but which is only valid under certain assumptions. The assumed context
records the assumptions taken during the construction of this scop and that need
to be code generated as a run-time test.
At the moment, we do not yet model any assumptions, but only added the
AssumedContext as well as the isl-ast generation support. As a next step,
this needs to be hooked up with the isl code generation.
if (1) /* run-time condition */
{ /* optimized code */ }
else
{ /* original code */ }
llvm-svn: 193652
Instead of defining the relevant functions inline, we now just keep the
declarations in the class itself. This makes the class declaration a lot
easier to read as all functions can be seen at once. We also use this
opportunity to privatize all functions not used in the public interface of the
class.
llvm-svn: 190841
Use 0 >= 1 instead of 0 != 0 to represent 'false'. This might be slightly more
efficient as isl may create a union of sets for 0 != 0, whereas this is never
needed for the expression 0 >= 1.
Contributed-by: Alexandre Isoard <alexandre.isoard@gmail.com>
llvm-svn: 190384
SCoP invariant parameters with the different start value would deter parameter
sharing. For example, when compiling the following C code:
void foo(float *input) {
for (long j = 0; j < 8; j++) {
// SCoP begin
for (long i = 0; i < 8; i++) {
float x = input[j * 64 + i + 1];
input[j * 64 + i] = x * x;
}
}
}
Polly would creat two parameters for these memory accesses:
p_0: {0,+,256}
p_2: {4,+,256}
[j * 64 + i + 1] => MemRef_input[o0] : 4o0 = p_1 + 4i0
[j * 64 + i] => MemRef_input[o0] : 4o0 = p_0 + 4i0
These parameters only differ from start value. To enable parameter sharing,
we split the start value from SCEVAddRecExpr, so they would share a single
parameter that always has zero start value:
p0: {0,+,256}<%for.cond1.preheader>
[j * 64 + i + 1] => MemRef_input[o0] : 4o0 = 4 + p_1 + 4i0
[j * 64 + i] => MemRef_input[o0] : 4o0 = p_0 + 4i0
Such translation can make the polly-dependence much faster.
Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 187728
In case we detect that the schedule the user wants to import is invalid we
refuse it _and_ free the isl_maps containing it.
Another bug found thanks to Rafael.
llvm-svn: 187339
We now use __isl_take to annotate the uses of the isl_set where we got the
memory management wrong.
Thanks to Rafael! His pipefail work hardened our test environment and exposed
this bug nicely.
llvm-svn: 187338
Split the old getNewValue into two parts:
1. The function "lookupAvailableValue" that return the new version of
the instruction which is already available.
2. The function calls "lookupAvailableValue", and tries to generate
the new version if it is not available yet.
llvm-svn: 187114
String operations resulted by raw_string_ostream in the INVALID macro can lead
to significant compile-time overhead when compiling large size source code.
This is because raw_string_ostream relies on TypeFinder class, whose
compile-time cost increases as the size of the module increases. This patch
targets to ensure that it only track detection failures if actually needed.
In this way, we can avoid expensive string operations in normal execution.
With this patch file, the relative compile-time cost of Polly-detect pass does
not increase even when compiling very large size source code.
Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 187102
Ensure that the scalar write access corresponds to the result of a load
instruction appears after the generic read access corresponds to the load
instruction.
llvm-svn: 186419
Orignally, we first test if a ValueMap contains a Value, and than use the
index operator to get the corresponding new value. This requires the ValueMap
to lookup the key (i.e. the old value) twice.
Now, we directly use the "lookup" function provided by DenseMap to implement
the same functionality.
llvm-svn: 185260
1. Do not allow creating new memory access record in the InstructionToAccess map
on the fly in function getAccessFor.
2. Do not allow user to modify the memory accesses returned by getAccessFor
during the code generation process.
llvm-svn: 185253
isl recently introduced isl_val as an abstract interface to represent arbitrary
precision numbers. This interface superseeds the old isl_int interface. In
contrast to the old interface which implemented arbitrary precision arithmetic
using macros that forward to the gmp library, the new library hides the math
library implementation in isl. This allows us to switch the math library used by
isl without affecting users such as Polly.
llvm-svn: 184529
Previously this happend to work for integers up to i64, but we got it wrong
for larger numbers. Fix this and add test cases to verify this keeps working.
Reported by: Sven Verdoolaege <skimo at kotnet dot org>
llvm-svn: 183986
When a region header is part of a loop, then all entering edges of this region
should not come from the loop but outside the region. Otherwise, the loop may be
only partially part of the region, which would cause troubles in handling
induction variables.
Currently, we can only model induction variables that are either fully part of
the scop (loop induction variable) or induction variables that are scop-
invariant (parameter). A loop that is only partially part of the
scop causes troubles, as there is no good way to handle the induction
variable in the independent blocks pass.
Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 183800
In GDB when "step" through generateScalarLoad and "finish" the call, the
returned value is non NULL, however when printing the value contained in
BBMap[Load] after this stmt:
BBMap[Load] = generateScalarLoad(...);
the value in BBMap[Load] is NULL, and the BBMap.count(Load) is 1.
The only intuitive idea that I have to explain this behavior is that we are
playing with the undefined behavior of eval order of the params for the function
standing for "BBMap[Load] = generateScalarLoad()". "BBMap[Load] = " may be
executed before generateScalarLoad is called.
Here are some other possible explanations from Will Dietz <w@wdtz.org>:
The error is likely due to BBMap[Load] being evaluated first (creating
a {Load -> uninitialized } entry in the DenseMap), then
generateScalarLoad eventually accesses the same element and finds it
to be NULL (DenseMap[Old]).. Offhand I'm not sure if this is
guaranteed to be NULL or if it's uninitialized and happens to be NULL.
The same issue can also go wrong in an even worse way: the second
DenseMap access can trigger a rehash and *invalidate* the an earlier
evaluated expression (for example LHS of the assignment), leading to a
crash when performing the assignment store.
llvm-svn: 182655
When the Polly code generation was written we did not correctly update the
LoopInfo data, but still claimed that the loop information is correct. This
does not only lead to missed optimizations, but it can also cause
miscompilations in case passes such as LoopSimplify are run after Polly.
Reported-by: Sergei Larin <slarin@codeaurora.org>
llvm-svn: 181987
BeforeBB
|
v
GuardBB
/ \
__ PreHeaderBB \
/ \ / |
latch HeaderBB |
\ / \ /
< \ /
\ /
ExitBB
This does not only remove the need for an explicit loop rotate pass, but it also
gives us the possibility to skip the construction of the guard condition in case
the loop is known to be executed at least once. We do not yet exploit this, but
by implementing this analysis in the isl code generator we should be able to
remove more guards than the generic loop rotate pass can. Another point is that
loop rotation can introduce additional PHI nodes, which may hide that a loop can
be executed in parallel. This change avoids this complication and will make it
easier to move the openmp code generation into a separate pass.
llvm-svn: 181986
Use the new cl::OptionCategory support to move the Polly options into a separate
option category. The aim is to hide most options and show by default only the
options a user needs to influence '-O3 -polly'. The available options probably
need some care, but here is the current status:
Polly Options:
Configure the polly loop optimizer
-enable-polly-openmp - Generate OpenMP parallel code
-polly - Enable the polly optimizer (only at -O3)
-polly-no-tiling - Disable tiling in the scheduler
-polly-only-func=<function-name> - Only run on a single function
-polly-report - Print information about the activities
of Polly
-polly-vectorizer - Select the vectorization strategy
=none - No Vectorization
=polly - Polly internal vectorizer
=unroll-only - Only grouped unroll the vectorize
candidate loops
=bb - The Basic Block vectorizer driven by
Polly
llvm-svn: 181295
In the classical (non -polly-codegen-scev) mode, we assume that we can always
recreate PHI nodes during code generation. This is not true. We can only
reconstruct them from the polyhedral information, in case the entire loop of the
PHI node is part of the SCoP and consequently the PHI node was translated in
the polyhedral description.
llvm-svn: 179674
We now support regions with multiple entries and multiple exits natively.
Regions are not needed to be simplified to single entry and single exit.
We need to XFAIL two test cases as this change increases the scop coverage
and uncoveres two failures in the independent blocks pass. The first failure
will be fixed in a subsequent commit, the second one is in the non-default
-polly-codegen-scev mode and still needs to be fixed.
Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 179673
Regions that have multiple entry edges are very common. A simple if condition
yields e.g. such a region:
if
/ \
then else
\ /
for_region
This for_region contains two entry edges 'then' -> 'for_region' and 'else' -> 'for_region'.
Previously we scheduled the RegionSimplify pass to translate such regions into
simple regions. With this patch, we now support them natively when the region is
in -loop-simplify form, which means the entry block should not be a loop header.
Contributed by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 179586
We do not only need to understand that 'k * p' is a parameter expression, but
also need to store this expression in the set of parameters. Before this patch
we wrongly stored the two individual parameters %k and %p.
Reported by: Sebastian Pop <spop@codeaurora.org>
llvm-svn: 179485
Statements with an empty iteration domain may not have a schedule assigned by
the isl schedule optimizer. As Polly expects each statement to have a schedule,
we keep the old schedule for such statements.
This fixes http://llvm.org/PR15645`
Reported-by: Johannes Doerfert <johannesdoerfert@gmx.de>
llvm-svn: 179233
Regions that have multiple exit edges are very common. A simple if condition
yields e.g. such a region:
if
/ \
then else
\ /
after
Region: if -> after
This regions contains the bbs 'if', 'then', 'else', but not 'after'. It has
two exit edges 'then' -> 'after' and 'else' -> 'after'.
Previously we scheduled the RegionSimplify pass to translate such regions into
simple regions. With this patch, we now support them natively.
Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 179159
During code generation we split the original entry and exit basic blocks
of the scop to make room for the newly generated code. To keep the region tree
up to date, we need to update the region tree. This patch ensures that not only
the region of the scop is updated, but also all child regions that share the
same entry or exit block.
We have now test case here, as the bug is only exposed by the subsequent commit.
The test cases of that commit also cover this bug.
Contributed-by: Star Tan <tanmx_star@yeah.net>
llvm-svn: 179158
Fix inspired from c2d4a0627e95c34a819b9d4ffb4db62daa78dade.
Given the following code
for (i = 0; i < 10; i++) {
;
}
S: A[i] = 0
When translate the data reference A[i] in statement S using scev, we need to
retrieve the scev of 'i' at the location of 'S'. If we do not do this the
scev that we obtain will be expressed as {0,+,1}_for and will reference loop
iterators that do not surround 'S'. What we really want is the scev to be
instantiated to the value of 'i' after the loop. This value is {10}.
This used to crash in:
int loopDimension = getLoopDepth(Expr->getLoop());
isl_aff *LAff = isl_aff_set_coefficient_si(
isl_aff_zero_on_domain(LocalSpace), isl_dim_in, loopDimension, 1);
(gdb) p Expr->dump()
{8,+,8}<nw><%do.body>
(gdb) p getLoopDepth(Expr->getLoop())
$5 = 0
isl_space *Space = isl_space_set_alloc(Ctx, 0, NbLoopSpaces);
isl_local_space *LocalSpace = isl_local_space_from_space(Space);
As we are trying to create a memory access in a stmt that is outside all loops,
LocalSpace has 0 dimensions:
(gdb) p NbLoopSpaces
$12 = 0
(gdb) p Statement.BB->dump()
if.then: ; preds = %do.end
%0 = load float* %add.ptr, align 4
store float %0, float* %q.1.reg2mem, align 4
br label %if.end.single_exit
and so the scev for %add.ptr should be taken at the place where it is used,
i.e., it should be the value on the last iteration of the do.body loop, and not
"{8,+,8}<nw><%do.body>".
llvm-svn: 179148
After this commit, polly is clang-format clean. This can be tested with
'ninja polly-check-format'. Updates to clang-format may change this, but the
differences will hopefully be both small and general improvements to the
formatting.
We currently have some not very nice formatting for a couple of items, DEBUG()
stmts for example. I believe the benefit of being clang-format clean outweights
the not perfect layout of this code.
llvm-svn: 177796
Given the following code
for (i = 0; i < 10; i++) {
;
}
S: A[i] = 0
When code generating S using scev based code generation, we need to retrieve
the scev of 'i' at the location of 'S'. If we do not do this the scev that
we obtain will be expressed as {0,+,1}_for and will reference loop iterators
that do not surround 'S' and that we consequently do not know how to code
generate. What we really want is the scev to be instantiated to the value of 'i'
after the loop. This value is {10} and it can be code generated without
troubles.
llvm-svn: 177777
Scev code generation can now handle scops with non canonical induction
variables. Hence there is no need to introduce canonical ones any more.
llvm-svn: 177644
We now detect scops without a canonical induction variable and can generate a
polyhedral representation for them. There was no modification necessary to
code generate these scops.
llvm-svn: 177643
When using the scev based code generation, we now do not rely on the presence
of a canonical induction variable any more. This commit prepares the path to
(conditionally) disable the induction variable canonicalization pass.
llvm-svn: 177548
This allows us to test Polly and the Polly optimizer without actually doing
code generation at the end. By enabling this option, we can also measure the
compile time overhead due to code generation and the cost of LLVM optimizing the
newly generated code.t
llvm-svn: 177516
When doing SCEV based code generation, we ignore instructions calculating values
that are fully defined by a SCEV expression. The values that are calculated by
this instructions are recalculated on demand.
This commit improves the check to verify if certain instructions can be ignored
and recalculated on demand.
llvm-svn: 177313
We now show the all members of the alias set that may couse possible aliasing.
In case a alias set member is not a named instruction (unnamed instructions or
constant expressions), we show the expression itself.
This improves our error message
from:
Possible aliasing for value: .reg2mem
to:
Possible aliasing: ".reg2mem",
"[0 x double]* inttoptr (i64 47255179264 to [0 x double]*)
llvm-svn: 174329
We fix the following formatting problems found by clang-format:
- 80 cols violations
- Obvious problems with missing or too many spaces
- multiple new lines in a row
clang-format suggests many more changes, most of them falling in the following
two categories:
1) clang-format does not at all format a piece of code nicely
2) The style that clang-format suggests does not match the style used in
Polly/LLVM
I consider differences caused by reason 1) bugs, which should be fixed by
improving clang-format. Differences due to 2) need to be investigated closer
to understand the cause of the difference and the solution that should be taken.
llvm-svn: 171241
Andreas Simbuerger