| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
The LLVMContext was only used for Diagnostic. Pass a DiagnosticHandler
instead.
Differential Revision: http://reviews.llvm.org/D14794
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 253540
|
|
|
|
|
|
|
|
| |
Ubsan detected undefined behavior in the MathExtras SaturatingMultiply test.
This change disables the test while it is being investigated.
llvm-svn: 253539
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14466
llvm-svn: 253521
|
|
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14360
rdar://problem/20820748
llvm-svn: 253520
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
1. remove uneeded header inclusion
2. use reinterpret_cast instead of c ctyle
3. other format change
llvm-svn: 253515
|
|
|
|
| |
llvm-svn: 253514
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 253509
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Post-commit review by David Blaikie, thanks David!
llvm-svn: 253494
|
|
|
|
|
|
|
|
|
| |
This change introduces an instrumentation intrinsic instruction for
value profiling purposes, the lowering of the instrumentation intrinsic
and raw reader updates. The raw profile data files for llvm-profdata
testing are updated.
llvm-svn: 253484
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a cost estimate for some missing sign and zero extensions. The
costs were determined by counting the number of shift instructions generated
without context for each new extension.
Differential Revision: http://reviews.llvm.org/D14730
llvm-svn: 253482
|
|
|
|
| |
llvm-svn: 253479
|
|
|
|
|
|
|
|
|
|
| |
profdata merge errors
Missed bit of feedback from D14720.
Use SmallSet<std::error_code> rather than std::set<...> in order to be more efficient.
llvm-svn: 253474
|
|
|
|
| |
llvm-svn: 253472
|
|
|
|
| |
llvm-svn: 253470
|
|
|
|
|
|
|
| |
These tests aren't testing that the result is valid syntax; they're testing
that the compiler emits the inline asm operands correctly.
llvm-svn: 253469
|
|
|
|
|
|
| |
operands.
llvm-svn: 253468
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also takes the push/pop syntax another step forward, introducing stack
slot numbers to make it easier to see how expressions are connected. For
example, the value pushed in $push7 is popped in $pop7.
And, this begins an experiment with making get_local and set_local implicit
when an operation directly uses or defines a register. This greatly reduces
clutter. If this experiment succeeds, it may make sense to do this for
const instructions as well.
And, this introduces more special code for ARGUMENTS; hopefully this code
will soon be obviated by proper support for live-in virtual registers.
llvm-svn: 253465
|
|
|
|
|
|
|
|
|
|
| |
Starting on an input stream that is not at offset 0 would trigger the
assert in WinCOFFObjectWriter.cpp:1065:
assert(getStream().tell() <= (*i)->Header.PointerToRawData &&
"Section::PointerToRawData is insane!");
llvm-svn: 253464
|
|
|
|
| |
llvm-svn: 253462
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The virtual register containing the address for returned value on
stack should in the DAG be represented with a CopyFromReg node and not
a Register node. Otherwise, InstrEmitter will not make sure that it
ends up in the right register class for the target instruction.
SystemZ needs this, becuause the reg class for address registers is a
subset of the general 64 bit register class.
test/SystemZ/CodeGen/args-07.ll and args-04.ll updated to run with
-verify-machineinstrs.
Reviewed by Hal Finkel.
llvm-svn: 253461
|
|
|
|
|
|
|
|
| |
(r252604)"
Failing clang test is now fixed by the r253458.
llvm-svn: 253459
|
|
|
|
|
|
|
|
| |
This time I've found a linux box and checked it there. This test now passes.
Because I'd introduced an undefined reference in @bar, gold now returns an error. This doesn't matter for the test itself, because it also emits the remarks the test is checking for. But it does cause LIT to notice a nonzero return code which it faults on.
llvm-svn: 253454
|
|
|
|
|
|
| |
Let's try again. This time using the right function signature. It's a real pity I can't run this on a darwin machine...
llvm-svn: 253453
|
|
|
|
|
|
| |
It needs the same fixes as in test/LTO/X86/remarks.ll, but this test appears not to get run on my system (but does on the buildbot). Strange.
llvm-svn: 253452
|
|
|
|
|
|
| |
Because we internalize early, we can potentially mark a bunch of functions as norecurse. Do this before globalopt.
llvm-svn: 253451
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14573
llvm-svn: 253450
|
|
|
|
| |
llvm-svn: 253449
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14766
llvm-svn: 253447
|
|
|
|
| |
llvm-svn: 253446
|
|
|
|
|
|
|
|
| |
DPSQX_S.W.PH, DPSQX_SA.W.PH, DPSU.H.QBL, DPSU.H.QBR and DPSX.W.PH instructions
Differential Revision: http://reviews.llvm.org/D14058
llvm-svn: 253443
|
|
|
|
|
|
| |
for more than a boolean check. NFC.
llvm-svn: 253441
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We use to have an odd difference among MapVector and SetVector. The map
used a DenseMop, but the set used a SmallSet, which in turn uses a
std::set.
I have changed SetVector to use a DenseSet. If you were depending on the
old behaviour you can pass an explicit set type or use SmallSetVector.
The common cases for needing to do it are:
* Optimizing for small sets.
* Sets for types not supported by DenseSet.
llvm-svn: 253439
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change teaches LLVM's inliner to track and suitably adjust
deoptimization state (tracked via deoptimization operand bundles) as it
inlines through call sites. The operation is described in more detail
in the LangRef changes.
Reviewers: reames, majnemer, chandlerc, dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14552
llvm-svn: 253438
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a section is rw, it is irrelevant if the dynamic linker will write to
it or not.
It looks like llvm implemented this because gcc was doing it. It looks
like gcc implemented this in the hope that it would put all the
relocated items close together and speed up the dynamic linker.
There are two problem with this:
* It doesn't work. Both bfd and gold will map .data.rel to .data and
concatenate the input sections in the order they are seen.
* If we want a feature like that, it can be implemented directly in the
linker since it knowns where the dynamic relocations are.
llvm-svn: 253436
|
|
|
|
| |
llvm-svn: 253432
|
|
|
|
|
|
| |
Forgot to do this simultaneously with committing the fix.
llvm-svn: 253430
|