| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 245053
|
| |
|
|
|
|
|
| |
This is better structurally and it also fixes a linker error in the configure
build.
llvm-svn: 245052
|
| |
|
|
|
|
|
|
|
|
|
| |
So, we now reject that. We also warn for any external-linkage global
variable named main in C, because it results in undefined behavior.
PR: 24309
Differential Revision: http://reviews.llvm.org/D11658
Reviewed by: rsmith
llvm-svn: 245051
|
| |
|
|
| |
llvm-svn: 245050
|
| |
|
|
| |
llvm-svn: 245049
|
| |
|
|
|
|
| |
can leave out the parameter list.
llvm-svn: 245048
|
| |
|
|
|
|
|
|
|
|
|
| |
Other than some places that were handling unknown as ELF, this should
have no change. The test updates are because we were detecting
arm-coff or x86_64-win64-coff as ELF targets before.
It is not clear if the enum should live on the Triple. At least now it lives
in a single location and should be easier to move somewhere else.
llvm-svn: 245047
|
| |
|
|
| |
llvm-svn: 245046
|
| |
|
|
|
|
|
|
|
|
| |
This is the first step for migrating cppmodernize to clang-tidy.
http://reviews.llvm.org/D11946
Patch by Angel Garcia!
llvm-svn: 245045
|
| |
|
|
|
|
|
|
|
|
|
| |
With this patch only the name is set. I will set the other fields shortly.
For now the table doesn't include local symbols. This is equivalent to using
--discard-all with gnu ld. This is OK for now since the symbols are not
needed for execution and for testing symbol resolution we only need the
global symbols.
llvm-svn: 245044
|
| |
|
|
|
|
|
|
|
|
| |
Before:
#elif(AAAA && BBBB)
After:
#elif (AAAA && BBBB)
llvm-svn: 245043
|
| |
|
|
|
|
|
|
|
|
|
| |
If there weren't any includes in the file, or all of them had 'IncludeKind'
greater than the desired one, then 'CreateIncludeInsertion' didn't work.
http://reviews.llvm.org/D12017
Patch by Angel Garcia!
llvm-svn: 245042
|
| |
|
|
|
|
|
| |
blender uses statements expression in condition of the loop under control of the '#pragma omp parallel for'. This condition is used several times in different expressions required for codegen of the loop directive. If there are some variables defined in statement expression, it fires an assert during codegen because of redefinition of the same variables.
We have to rebuild several expression to be sure that all variables are unique.
llvm-svn: 245041
|
| |
|
|
|
|
|
|
|
|
|
| |
Fix a bug in the matcher docs where callExpr(on(...)) was in the examples,
but didn't work (on() only works for memberCallExpr).
Fix a bug in the doc dump script that was introduced in r231575 when
removing a regexp capture without adapting the code that uses the
captures.
llvm-svn: 245040
|
| |
|
|
|
|
|
| |
This allows other areas of the compiler to use BDCE's bit-tracking.
NFCI.
llvm-svn: 245039
|
| |
|
|
| |
llvm-svn: 245038
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, arguments are passed via the string attribute 'command',
assuming a shell-escaped / quoted command line to extract the original
arguments. This works well enough on Unix systems, but turns out to be
problematic for Windows tools to generate.
This CL adds a new attribute 'arguments', an array of strings, which
specifies the exact command line arguments. If 'arguments' is available
in the compilation database, it is preferred to 'commands'.
Currently there is no plan to retire 'commands': there are enough
different use cases where users want to create their own mechanism for
creating compilation databases, that it doesn't make sense to force them
all to implement shell command line parsing.
Patch by Daniel Dilts.
llvm-svn: 245036
|
| |
|
|
|
|
|
|
| |
Spotted by Ahmed - in r244594 I inadvertently marked f16 min/max as legal.
I've reverted it here, and marked min/max on scalar f16's as promote. I've also added a testcase. The test just checks that the compiler doesn't fall over - it doesn't create fmin nodes for f16 yet.
llvm-svn: 245035
|
| |
|
|
|
|
| |
base class anyways.
llvm-svn: 245034
|
| |
|
|
|
|
| |
to CompilerType.
llvm-svn: 245033
|
| |
|
|
| |
llvm-svn: 245032
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code-section alignment should be at least as high as the minimum
stub alignment. If the section alignment is lower it can cause
padding to be emitted resulting in alignment errors if the section
is mapped to a higher alignment on the target.
E.g. If a text section with a 4-byte alignment gets 4-bytes of
padding to guarantee 8-byte alignment for stubs but is re-mapped to
an 8-byte alignment on the target, the 4-bytes of padding will push
the stubs to 4-byte alignment causing a crash.
No test case: There is currently no way to control host section
alignment in llvm-rtdyld. This could be made testable by adding
a custom memory manager. I'll look at that in a follow-up patch.
llvm-svn: 245031
|
| |
|
|
| |
llvm-svn: 245030
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces the basic functionality to support "token types".
The motivation stems from the need to perform operations on a Value
whose provenance cannot be obscured.
There are several applications for such a type but my immediate
motivation stems from WinEH. Our personality routine enforces a
single-entry - single-exit regime for cleanups. After several rounds of
optimizations, we may be left with a terminator whose "cleanup-entry
block" is not entirely clear because control flow has merged two
cleanups together. We have experimented with using labels as operands
inside of instructions which are not terminators to indicate where we
came from but found that LLVM does not expect such exotic uses of
BasicBlocks.
Instead, we can use this new type to clearly associate the "entry point"
and "exit point" of our cleanup. This is done by having the cleanuppad
yield a Token and consuming it at the cleanupret.
The token type makes it impossible to obscure or otherwise hide the
Value, making it trivial to track the relationship between the two
points.
What is the burden to the optimizer? Well, it turns out we have already
paid down this cost by accepting that there are certain calls that we
are not permitted to duplicate, optimizations have to watch out for
such instructions anyway. There are additional places in the optimizer
that we will probably have to update but early examination has given me
the impression that this will not be heroic.
Differential Revision: http://reviews.llvm.org/D11861
llvm-svn: 245029
|
| |
|
|
|
|
|
|
|
|
|
| |
file in the .pcm files. This allows a smaller set of files to be sent to a
remote build worker when building with explicit modules (for instance, module
map files need not be sent along with the corresponding precompiled modules).
This doesn't actually make the embedded files visible to header search, so
it's not useful as a packaging format for public header files.
llvm-svn: 245028
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D12024
llvm-svn: 245027
|
| |
|
|
|
|
|
|
|
|
|
| |
SUMMARY:
This patch adds support of floating point and aggregate return types in GetReturnValueObjectImpl() for mips64.
Reviewers: clayborg, jingham
Subscribers: mohit.bhakkad, nitesh.jain, sagar, jaydeep, lldb-commits
Differential Revision: http://reviews.llvm.org/D11641
llvm-svn: 245026
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch enables dead stroe elimination across basicblocks.
Example:
define void @test_02(i32 %N) {
%1 = alloca i32
store i32 %N, i32* %1
store i32 10, i32* @x
%2 = load i32, i32* %1
%3 = icmp ne i32 %2, 0
br i1 %3, label %4, label %5
; <label>:4
store i32 5, i32* @x
br label %7
; <label>:5
%6 = load i32, i32* @x
store i32 %6, i32* @y
br label %7
; <label>:7
store i32 15, i32* @x
ret void
}
In the above example dead store "store i32 5, i32* @x" is now eliminated.
Differential Revision: http://reviews.llvm.org/D11143
llvm-svn: 245025
|
| |
|
|
|
|
| |
normalize its formatting before I make more substantial changes.
llvm-svn: 245024
|
| |
|
|
|
|
| |
their headers.
llvm-svn: 245023
|
| |
|
|
|
|
| |
Identified by the clang static analyzer. No functional change intended.
llvm-svn: 245022
|
| |
|
|
|
|
|
|
|
| |
its creation function.
This required shifting a bunch of method definitions to be out-of-line
so that we could leave most of the implementation guts in the .cpp file.
llvm-svn: 245021
|
| |
|
|
|
|
|
|
|
|
|
| |
SUMMARY:
This patch adds support of floating point and aggregate return types in GetReturnValueObjectImpl() for mips32
Reviewers: clayborg
Subscribers: mohit.bhakkad, nitesh.jain, sagar, jaydeep, lldb-commits
Differential Revision: http://reviews.llvm.org/D11930
llvm-svn: 245020
|
| |
|
|
|
|
| |
its creation function. Update the relevant includes accordingly.
llvm-svn: 245019
|
| |
|
|
|
|
|
|
|
| |
This is more convenient than the offset from the start of the file as we
don't have to worry about it changing when we move the output section.
This is a port of r245008 from ELF.
llvm-svn: 245018
|
| |
|
|
|
|
| |
before making substantial changes.
llvm-svn: 245017
|
| |
|
|
|
|
| |
creating this header.
llvm-svn: 245016
|
| |
|
|
| |
llvm-svn: 245015
|
| |
|
|
|
|
| |
formatting.
llvm-svn: 245014
|
| |
|
|
|
|
| |
creation function into that header.
llvm-svn: 245013
|
| |
|
|
|
|
|
|
|
| |
creation function there.
Same basic refactoring as the other alias analyses. Nothing special
required this time around.
llvm-svn: 245012
|
| |
|
|
|
|
|
| |
satisfy libc++'s std::forward_list which requires the value type to be
complete.
llvm-svn: 245011
|
| |
|
|
|
|
| |
substantial changes to normalize any formatting.
llvm-svn: 245010
|
| |
|
|
|
|
|
|
|
|
| |
I've used forward declarations and reorderd the source code some to make
this reasonably clean and keep as much of the code as possible in the
source file, including all the stratified set details. Just the basic AA
interface and the create function are in the header file, and the header
file is now included into the relevant locations.
llvm-svn: 245009
|
| |
|
|
|
|
| |
For now it is empty. I will add the symbols in a followup patch.
llvm-svn: 245008
|
| |
|
|
|
|
|
|
|
|
|
| |
the AA counter pass.
For pointsToConstantMemory, I think this is a "bug fix" as I think the
code as written will actually infloop if ever reached. For the
getModRefInfo, this is a no-op change but with a significantly simpler
form.
llvm-svn: 245007
|
| |
|
|
|
|
|
|
|
| |
.cpp file to make the header much less noisy.
Also makes it easy to use a static helper rather than a public method
for printing lines of stats.
llvm-svn: 245006
|
| |
|
|
|
|
| |
for subsequent changes.
llvm-svn: 245005
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
pattern.
Also hoist the creation routine out of the generic header and into the
pass header now that we have one.
I've worked to not make any changes, even formatting ones here. I'll
clean up the formatting and other things in a follow-up patch now that
the code is in the right place.
llvm-svn: 245004
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sign-overflow.
Summary:
This patch implements my promised optimization to reunites certain sexts from
operands after we extract the constant offset. See the header comment of
reuniteExts for its motivation.
One key building block that enables this optimization is Bjarke's poison value
analysis (D11212). That helps to prove "a +nsw b" can't overflow.
Reviewers: broune
Subscribers: jholewinski, sanjoy, llvm-commits
Differential Revision: http://reviews.llvm.org/D12016
llvm-svn: 245003
|