| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Ubsan detected undefined behavior in the MathExtras SaturatingMultiply test.
This change disables the test while it is being investigated.
llvm-svn: 253539
|
| |
|
|
|
|
|
| |
try to CreateInstance, and log the results. I copied that for the
Mac platforms.
llvm-svn: 253538
|
| |
|
|
| |
llvm-svn: 253537
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Optimizations like LoadPRE in GVN will insert new instructions.
If the insertion point is in a already processed BB, they should
get a value number explicitly. If the insertion point is after
current instruction, then just leave it. However, current GVN framework
has no support for it.
In this patch, we just bail out if a VN can't be found.
Dfferential Revision: http://reviews.llvm.org/D14670
A test/Transforms/GVN/pr25440.ll
M lib/Transforms/Scalar/GVN.cpp
llvm-svn: 253536
|
| |
|
|
|
|
| |
std::coroutine_traits.
llvm-svn: 253535
|
| |
|
|
|
|
|
|
|
|
|
| |
driving a canonical difference between that and an unqualified
type is a really bad idea when both are valid. Instead, remember
that it was there in a non-canonical way, then look for that in
the one place we really care about it: block captures. The net
effect closely resembles the behavior of a decl attribute, except
still closely following ARC's standard qualifier parsing rules.
llvm-svn: 253534
|
| |
|
|
|
|
|
|
|
| |
to start at the offset of the first ivar instead of the rounded-up
end of the superclass. The latter could include a large amount of
tail padding because of a highly-aligned ivar, and subclass ivars
can be laid out within that.
llvm-svn: 253533
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Conversions between unrelated pointer types (e.g. char * and void *) involve
bitcasts which were not properly modeled in case of static initializers. The
patch fixes this problem.
The problem was originally spotted by Artem Dergachev. Patched by Yuri Gribov!
Differential Revision: http://reviews.llvm.org/D14652
llvm-svn: 253532
|
| |
|
|
|
|
| |
part of frame formatting
llvm-svn: 253531
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
dlopen(NULL, ...) is intended to give you back a handle to the
executable for use with dlsym. Casting it to link_map and using it with
ForEachMappedRegion results in a crash.
We also shouldn't unpoison the globals of a DSO that is already in
memory. This ensures that we don't do it for the executable, but in
general, MSan may have false negatives if the DSO is already loaded.
Reviewers: eugenis
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14795
llvm-svn: 253530
|
| |
|
|
| |
llvm-svn: 253529
|
| |
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14156
rdar://problem/21118279
llvm-svn: 253528
|
| |
|
|
| |
llvm-svn: 253527
|
| |
|
|
|
|
|
|
|
|
|
|
| |
On the average user's system, those libraries will not be compiled with
MSan. Prior to this change, the LLVM test suite was full of false
positives from calls from third party libraries to MSan interceptors
like strlen.
We can remove this check if MSan ever grows a suppression mechanism
similar to TSan's.
llvm-svn: 253526
|
| |
|
|
| |
llvm-svn: 253525
|
| |
|
|
|
|
| |
into the DAG
llvm-svn: 253524
|
| |
|
|
|
|
|
|
|
|
|
| |
In the Microsoft ABI, the vftable is laid out in the order in the
declaration order of the entities defined within it.
Obviously, only virtual methods end up in the vftable but they will be
placed into the table at the same position as the first entity with the
same name.
llvm-svn: 253523
|
| |
|
|
| |
llvm-svn: 253522
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14466
llvm-svn: 253521
|
| |
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14360
rdar://problem/20820748
llvm-svn: 253520
|
| |
|
|
|
|
|
|
|
|
|
| |
The conversion from QuantityType to the (temporary) IntegerAlignment class
was ambiguous.
For now add in explicit conversion to unsigned to satisfy the clang-x86_64-debian-fast bot.
I'll remove the explicit conversion when I remove the IntegerAlignment class.
llvm-svn: 253519
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bug would manifest in some very specific cases where all the following
conditions are fullfilled:
- GVN didn't remove block
- The regular GVN iteration didn't change the IR
- PRE is enabled
- PRE will not split critical edge
- The last instruction processed by PRE didn't change the IR
Because the CallGraph PassManager relies on this returned value to decide
if it needs to recompute a node after the execution of Function passes,
not returning the right value can lead to unexpected results.
Fix for: https://llvm.org/bugs/show_bug.cgi?id=24715
Patch by Wenxiang Qiu <vincentqiuuu@gmail.com>
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 253518
|
| |
|
|
|
|
| |
I'm unaware of any reasons why -fvisibility-inlines-hidden would depend on PIC, and since autoconf supports this flag without PIC, we should support it in CMake too.
llvm-svn: 253517
|
| |
|
|
|
|
|
|
|
|
|
| |
Since we don't check functions in dependent contexts, we should skip blocks
in those contexts as well. This avoids an assertion failure when the
DeadStoresChecker attempts to evaluate an array subscript expression with
a dependent name type.
rdar://problem/23564220
llvm-svn: 253516
|
| |
|
|
|
|
|
|
| |
1. remove uneeded header inclusion
2. use reinterpret_cast instead of c ctyle
3. other format change
llvm-svn: 253515
|
| |
|
|
| |
llvm-svn: 253514
|
| |
|
|
|
|
|
| |
This closes:
http://reviews.llvm.org/D14783
llvm-svn: 253513
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow on from a similar LLVM commit: r253511.
Note, this was reviewed (and more details are in) http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html
These intrinsics currently have an explicit alignment argument which is
required to be a constant integer. It represents the alignment of the
source and dest, and so must be the minimum of those.
This change allows source and dest to each have their own alignments
by using the alignment attribute on their arguments. The alignment
argument itself is removed.
The only code change to clang is hidden in CGBuilder.h which now passes
both dest and source alignment to IRBuilder, instead of taking the minimum of
dest and source alignments.
Reviewed by Hal Finkel.
llvm-svn: 253512
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note, this was reviewed (and more details are in) http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html
These intrinsics currently have an explicit alignment argument which is
required to be a constant integer. It represents the alignment of the
source and dest, and so must be the minimum of those.
This change allows source and dest to each have their own alignments
by using the alignment attribute on their arguments. The alignment
argument itself is removed.
There are a few places in the code for which the code needs to be
checked by an expert as to whether using only src/dest alignment is
safe. For those places, they currently take the minimum of src/dest
alignments which matches the current behaviour.
For example, code which used to read:
call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 500, i32 8, i1 false)
will now read:
call void @llvm.memcpy.p0i8.p0i8.i32(i8* align 8 %dest, i8* align 8 %src, i32 500, i1 false)
For out of tree owners, I was able to strip alignment from calls using sed by replacing:
(call.*llvm\.memset.*)i32\ [0-9]*\,\ i1 false\)
with:
$1i1 false)
and similarly for memmove and memcpy.
I then added back in alignment to test cases which needed it.
A similar commit will be made to clang which actually has many differences in alignment as now
IRBuilder can generate different source/dest alignments on calls.
In IRBuilder itself, a new argument was added. Instead of calling:
CreateMemCpy(Dst, Src, getInt64(Size), DstAlign, /* isVolatile */ false)
you now call
CreateMemCpy(Dst, Src, getInt64(Size), DstAlign, SrcAlign, /* isVolatile */ false)
There is a temporary class (IntegerAlignment) which takes the source alignment and rejects
implicit conversion from bool. This is to prevent isVolatile here from passing its default
parameter to the source alignment.
Note, changes in future can now be made to codegen. I didn't change anything here, but this
change should enable better memcpy code sequences.
Reviewed by Hal Finkel.
llvm-svn: 253511
|
| |
|
|
| |
llvm-svn: 253510
|
| |
|
|
| |
llvm-svn: 253509
|
| |
|
|
|
|
|
|
|
| |
1. Added missing public API decl in InstrProfiling.h
2. Clang formatting fix
3. Added more comments for new VP code
4. refactor the VP allocation code to make it more readable.
llvm-svn: 253508
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14785
llvm-svn: 253507
|
| |
|
|
|
|
| |
Too much code is sloppy about this to error by default.
llvm-svn: 253506
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14784
llvm-svn: 253505
|
| |
|
|
|
|
|
|
|
|
| |
This patch adds support for vector constant folding of integer/float comparisons.
This requires FoldConstantVectorArithmetic to support scalar constant operands (in this case ISD::CONDCASE). In future we should be able to support other scalar constant types as necessary (and possibly start calling FoldConstantVectorArithmetic for all node creations)
Differential Revision: http://reviews.llvm.org/D14683
llvm-svn: 253504
|
| |
|
|
| |
llvm-svn: 253503
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It turns out we decide whether to use SjLj exceptions or some alternative in
two separate places in the backend, and they disagreed with each other. This
led to inconsistent code and is generally a terrible idea.
So make them consistent and add an assert that they *do* match (unfortunately
MCAsmInfo isn't available in opt, so it can't be used to initialise the CodeGen
version directly).
llvm-svn: 253502
|
| |
|
|
| |
llvm-svn: 253501
|
| |
|
|
|
|
|
|
|
| |
With this change, Buffer API and File API implementations
are unified.
Differential Revision: http://reviews.llvm.org/D14692
llvm-svn: 253500
|
| |
|
|
|
|
|
|
| |
Summary: Fix for https://llvm.org/bugs/show_bug.cgi?id=25550
Differential Revision: http://reviews.llvm.org/D14764
llvm-svn: 253499
|
| |
|
|
|
|
|
|
| |
Summary: Fix for https://llvm.org/bugs/show_bug.cgi?id=25550
Differential Revision: http://reviews.llvm.org/D14763
llvm-svn: 253498
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change adds MathExtras helper functions for handling unsigned, saturating addition and multiplication. It also updates the instrumentation and sample profile merge implementations to use them.
Reviewers: dnovillo, bogner, davidxl
Subscribers: davidxl, llvm-commits
Differential Revision: http://reviews.llvm.org/D14720
llvm-svn: 253497
|
| |
|
|
| |
llvm-svn: 253496
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We created a malformed TemplateSpecializationType: it was dependent but
had a RecordType as it's canonical type. This would lead getAs to
crash. r249090 worked around this but we should fix this for real by
providing a more appropriate template specialization type as the
canonical type.
This fixes PR24246.
llvm-svn: 253495
|
| |
|
|
|
|
| |
Post-commit review by David Blaikie, thanks David!
llvm-svn: 253494
|
| |
|
|
|
|
| |
model, as well as the type X list commands), along with a change by Zachary Turner to bypass a MSVC bug with SFINAE
llvm-svn: 253493
|
| |
|
|
| |
llvm-svn: 253492
|
| |
|
|
|
|
| |
This logically goes with my previous commit.
llvm-svn: 253491
|
| |
|
|
|
|
|
|
| |
to prepare_bindings.py.
Xcode moved off of build-swig-wrapper-classes.sh earlier this week.
llvm-svn: 253490
|