Age | Commit message (Collapse) | Author | Files | Lines |
|
This is meant to be used when testing dot releases e.g.:
./test-release -release 3.3 -dot 1 -rc 1
llvm-svn: 190581
|
|
llvm-svn: 190580
|
|
This should hopefully fix
http://lab.llvm.org:8011/builders/clang-x86_64-darwin11-self-mingw32
Merged from r182446
Author: Rafael Espindola <rafael.espindola@gmail.com>
Date: Wed May 22 02:30:47 2013 +0000
llvm-svn: 190579
|
|
in functions which call __builtin_unwind_init()
__builtin_unwind_init() is an undocumented gcc intrinsic which has this effect,
and is used in libgcc_eh.
Goes part of the way toward fixing PR8541.
Merged from r183984
Author: Derek Schuff <dschuff@google.com>
Date: Fri Jun 14 16:15:29 2013 +0000
llvm-svn: 190578
|
|
llvm-svn: 190577
|
|
When a function is inlined we lazily construct the variables
representing the function's parameters. After that, we add any remaining
unused parameters.
If the function doesn't use all the parameters, or uses them out of
order, then the DWARF would produce them in that order, producing a
parameter order that doesn't match the source.
This fix causes us to always keep the arg variables at the start of the
variable list & in the original order from the source.
Merged from r183297
Author: David Blaikie <dblaikie@gmail.com>
Date: Wed Jun 5 05:39:59 2013 +0000
llvm-svn: 186678
|
|
Merged from r182190
Author: Tim Northover <t.p.northover@gmail.com>
Date: Sat May 18 08:17:47 2013 +0000
llvm-svn: 186677
|
|
succession. Fixes PR16363.
Merged from r184240
Author: Eli Friedman <eli.friedman@gmail.com>
Date: Tue Jun 18 21:33:38 2013 +0000
llvm-svn: 186204
|
|
vectorizing loops with memory accesses to non-zero address spaces. It
simply dropped the AS info. Fixes PR16306.
Merged from r184103
Author: Pekka Jaaskelainen <pekka.jaaskelainen@tut.fi>
Date: Mon Jun 17 18:49:06 2013 +0000
llvm-svn: 185869
|
|
Patch by: Vincent Lejeune
https://bugs.freedesktop.org/show_bug.cgi?id=64877
NOTE: This is a candidate for the 3.3 branch.
Merged from r182600
Author: Tom Stellard <thomas.stellard@amd.com>
Date: Thu May 23 18:26:42 2013 +0000
llvm-svn: 185868
|
|
llvm-svn: 184287
|
|
merge from trunk.
- Also split out a section on build portability and updated the list of features and improvements.
--- This now reflects the up-coming merge of patches from trunk into the release_33 branch.
llvm-svn: 183554
|
|
llvm-svn: 183500
|
|
llvm-svn: 183396
|
|
llvm-svn: 183386
|
|
The original test case showed a problem with the independet blocks pass and
we decided to XFAIL it for now. Unfortunately the failure is not detected if
we build without asserts and the verification of the independent block pass
is not run. This change tests now for the actual reason of the failure and
should trigger even in a non asserts build. We did not yet solve the underlying
bug, but this should at least make the test suite behavior consistent.
Merged from: https://llvm.org/svn/llvm-project/polly/trunk@183025
llvm-svn: 183384
|
|
to be able to compile with ISL master as of today
1df91d8515ec88dc7f7f597168ad0f34f26de5a7
Merged from: https://llvm.org/svn/llvm-project/polly/trunk@183023
llvm-svn: 183383
|
|
to detect scops in functions with no loops, use -polly-detect-scops-in-functions-without-loops
Merged from: https://llvm.org/svn/llvm-project/polly/trunk@182941
llvm-svn: 183382
|
|
Merged from: https://llvm.org/svn/llvm-project/polly/trunk@182662
llvm-svn: 183381
|
|
Merged from: https://llvm.org/svn/llvm-project/polly/trunk@182661
llvm-svn: 183380
|
|
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.
Merged from: https://llvm.org/svn/llvm-project/polly/trunk@182655
llvm-svn: 183379
|
|
It was initially committed to allow people to get a list of the files used
or generated in the matmul tutorial. Since the documentation does now
point people to the directory in their git checkout, it is not necessary anymore
to make a directory listing available. Especially, as this never worked and
recently the LLVM web server does not deliver files in this directory at all
due to the unsupported .htaccess file.
Merged from: https://llvm.org/svn/llvm-project/polly/trunk@182370
llvm-svn: 183378
|
|
Merged from: https://llvm.org/svn/llvm-project/polly/trunk@182310
llvm-svn: 183377
|
|
As the namings of the scops have changed, polly was not able to read in the user
given .jscop files. By renaming the provided files, polly now finds them again
and can use them to optimize the matmul function. We also update the generated
files to reflect the very latest version of Polly.
Merged from: https://llvm.org/svn/llvm-project/polly/trunk@182265
llvm-svn: 183376
|
|
other llvm projects
Merged from: https://llvm.org/svn/llvm-project/polly/trunk@182171
llvm-svn: 183375
|
|
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>
Merged from: https://llvm.org/svn/llvm-project/polly/trunk@181987
llvm-svn: 183374
|
|
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.
Merged from https://llvm.org/svn/llvm-project/polly/trunk@181986
llvm-svn: 183373
|
|
llvm-svn: 183249
|
|
------------------------------------------------------------------------
r183060 | atrick | 2013-05-31 16:34:46 -0700 (Fri, 31 May 2013) | 11 lines
Prevent loop-unroll from making assumptions about undefined behavior.
Fixes rdar:14036816, PR16130.
There is an opportunity to compute precise trip counts for 'or'
expressions and multi-exit loops.
rdar:14038809: Optimize trip count computation for multi-exit loops.
To do this we need to record the fact that ExitLimit assumes NSW. When
it does not we can safely assume that the loop trip count is the
minimum ExitLimt across all subexpressions and loop exits.
------------------------------------------------------------------------
llvm-svn: 183246
|
|
------------------------------------------------------------------------
r182989 | atrick | 2013-05-30 23:43:25 -0700 (Thu, 30 May 2013) | 13 lines
Fix ScalarEvolution::ComputeExitLimitFromCond for 'or' conditions.
Fixes PR16130 - clang produces incorrect code with loop/expression at -O2.
This is a 2+ year old bug that's now holding up the release. It's a
case where we knowingly made aggressive assumptions about undefined
behavior. These assumptions are wrong when SCEV is computing a
subexpression that does not directly control the branch. With this
fix, we avoid making assumptions in those cases but still optimize the
common case. SCEV's trip count computation for exits controlled by
'or' expressions is now analagous to the trip count computation for
loops with multiple exits. I had already fixed the multiple exit case
to be conservative.
------------------------------------------------------------------------
llvm-svn: 183245
|
|
llvm-svn: 183212
|
|
llvm-svn: 183208
|
|
llvm-svn: 183207
|
|
------------------------------------------------------------------------
r183153 | dmalea | 2013-06-03 13:45:54 -0700 (Mon, 03 Jun 2013) | 7 lines
Fix crash (in optimized builds) due to invalid metadata operand
- ConstantDataArray is not a valid MDNode operand
- encode function-name strings in metadata by wrapping in an MDString instead
- should resolve reported by http://llvm-jenkins.debian.net/job/llvm-toolchain-quantal-binaries/architecture=amd64,distribution=quantal/173/
------------------------------------------------------------------------
llvm-svn: 183191
|
|
------------------------------------------------------------------------
llvm-svn: 183190
|
|
------------------------------------------------------------------------
r183035 | arnolds | 2013-05-31 12:53:50 -0700 (Fri, 31 May 2013) | 7 lines
LoopVectorize: PHIs with only outside users should prevent vectorization
We check that instructions in the loop don't have outside users (except if
they are reduction values). Unfortunately, we skipped this check for
if-convertable PHIs.
Fixes PR16184.
------------------------------------------------------------------------
llvm-svn: 183189
|
|
------------------------------------------------------------------------
r183108 | vljn | 2013-06-03 08:44:42 -0700 (Mon, 03 Jun 2013) | 1 line
R600: CALL_FS consumes a stack size entry
------------------------------------------------------------------------
llvm-svn: 183181
|
|
Improve support for compiler-rt tests in CMake build.
Now compiler-rt tests run correctly if compiler-rt is checked out into
arbitrary directory (not necessarily projects/compiler-rt).
Patch by Greg Fitzgerald!
llvm-svn: 183180
|
|
behavior.
Fixes rdar:14036816, PR16130.
There is an opportunity to compute precise trip counts for 'or'
expressions and multi-exit loops.
rdar:14038809: Optimize trip count computation for multi-exit loops.
To do this we need to record the fact that ExitLimit assumes NSW. When
it does not we can safely assume that the loop trip count is the
minimum ExitLimt across all subexpressions and loop exits.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183060 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-svn: 183066
|
|
conditions.
Fixes PR16130 - clang produces incorrect code with loop/expression at -O2.
This is a 2+ year old bug that's now holding up the release. It's a
case where we knowingly made aggressive assumptions about undefined
behavior. These assumptions are wrong when SCEV is computing a
subexpression that does not directly control the branch. With this
fix, we avoid making assumptions in those cases but still optimize the
common case. SCEV's trip count computation for exits controlled by
'or' expressions is now analagous to the trip count computation for
loops with multiple exits. I had already fixed the multiple exit case
to be conservative.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182989 91177308-0d34-0410-b5e6-96231b3b80d8
llvm-svn: 183013
|
|
------------------------------------------------------------------------
r182645 | eugenis | 2013-05-24 07:28:03 -0700 (Fri, 24 May 2013) | 6 lines
Add -lrt to sanitizer link arguments.
Sanitizer runtime intercepts functions from librt. Not doing this will fail
if the librt dependency is not present at program startup (ex. comes from a
dlopen()ed library).
------------------------------------------------------------------------
llvm-svn: 182944
|
|
------------------------------------------------------------------------
r182585 | aaronballman | 2013-05-23 07:55:00 -0700 (Thu, 23 May 2013) | 1 line
Setting the default value (fixes CRT assertions about uninitialized variable use when doing debug MSVC builds), and fixing coding style.
------------------------------------------------------------------------
llvm-svn: 182830
|
|
------------------------------------------------------------------------
r182394 | jholewinski | 2013-05-21 09:51:30 -0700 (Tue, 21 May 2013) | 1 line
[NVPTX] Add @llvm.nvvm.sqrt.f() intrinsic
------------------------------------------------------------------------
llvm-svn: 182829
|
|
------------------------------------------------------------------------
r182298 | jholewinski | 2013-05-20 09:42:18 -0700 (Mon, 20 May 2013) | 1 line
[NVPTX] Fix mis-use of CurrentFnSym in NVPTXAsmPrinter. This was causing a symbol name error in the output PTX.
------------------------------------------------------------------------
llvm-svn: 182828
|
|
------------------------------------------------------------------------
r182297 | jholewinski | 2013-05-20 09:42:16 -0700 (Mon, 20 May 2013) | 1 line
[NVPTX] Add programmatic interface to NVVMReflect pass
------------------------------------------------------------------------
llvm-svn: 182827
|
|
------------------------------------------------------------------------
r182254 | jholewinski | 2013-05-20 05:13:32 -0700 (Mon, 20 May 2013) | 12 lines
[NVPTX] Add GenericToNVVM IR converter to better handle idiomatic LLVM IR inputs
This converter currently only handles global variables in address space 0. For
these variables, they are promoted to address space 1 (global memory), and all
uses are updated to point to the result of a cvta.global instruction on the new
variable.
The motivation for this is address space 0 global variables are illegal since we
cannot declare variables in the generic address space. Instead, we place the
variables in address space 1 and explicitly convert the pointer to address
space 0. This is primarily intended to help new users who expect to be able to
place global variables in the default address space.
------------------------------------------------------------------------
llvm-svn: 182826
|
|
------------------------------------------------------------------------
r182253 | jholewinski | 2013-05-20 05:13:28 -0700 (Mon, 20 May 2013) | 1 line
[NVPTX] Fix i1 kernel parameters and global variables. ABI rules say we need to use .u8 for i1 parameters for kernels.
------------------------------------------------------------------------
llvm-svn: 182825
|
|
------------------------------------------------------------------------
r182656 | d0k | 2013-05-24 11:05:35 -0700 (Fri, 24 May 2013) | 3 lines
LoopVectorize: LoopSimplify can't canonicalize loops with an indirectbr in it, don't assert on those cases.
Fixes PR16139.
------------------------------------------------------------------------
llvm-svn: 182785
|
|
--- Reverse-merging r182522 into '.':
U source/Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.cpp
U .
--- Reverse-merging r182521 into '.':
U source/Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.cpp
G .
--- Reverse-merging r182520 into '.':
U source/Core/ValueObjectVariable.cpp
G .
--- Reverse-merging r182519 into '.':
U source/Symbol/Variable.cpp
G .
--- Reverse-merging r182518 into '.':
U source/Plugins/Process/Linux/ProcessMonitor.cpp
U source/Plugins/Process/Linux/ProcessLinux.h
G .
--- Reverse-merging r182517 into '.':
G source/Plugins/Process/Linux/ProcessMonitor.cpp
G .
--- Reverse-merging r182516 into '.':
U source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
U source/Expression/DWARFExpression.cpp
U source/Expression/Materializer.cpp
U source/Expression/ClangExpressionDeclMap.cpp
G .
llvm-svn: 182525
|
|
------------------------------------------------------------------------
r182441 | gclayton | 2013-05-21 17:10:28 -0700 (Tue, 21 May 2013) | 5 lines
<rdar://problem/13455021>
Another fix to make sure that if we aren't able to extract an object file for any reason, we don't crash when trying to parse the debug map info.
------------------------------------------------------------------------
llvm-svn: 182522
|