| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 333514
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These intrinsics are used by MSVC's header files on AArch64 Windows as
well as AArch32, so we should support them for both targets. I've
factored them out of CodeGenFunction::EmitARMBuiltinExpr into separate
functions that EmitAArch64BuiltinExpr can call as well.
Reviewers: javed.absar, mstorsjo
Reviewed By: mstorsjo
Subscribers: kristof.beyls, cfe-commits
Differential Revision: https://reviews.llvm.org/D47476
llvm-svn: 333513
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The fX version of floating-point registers only supports
single precision. We need to map the name to dX for doubles and qX
for long doubles if we want getRegForInlineAsmConstraint() to be
able to pick the correct register class.
Reviewers: jyknight, venkatra
Reviewed By: jyknight
Subscribers: eraman, fedor.sergeev, jrtc27, llvm-commits
Differential Revision: https://reviews.llvm.org/D47258
llvm-svn: 333512
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: jyknight
Reviewed By: jyknight
Subscribers: eraman, fedor.sergeev, jrtc27, cfe-commits
Differential Revision: https://reviews.llvm.org/D47137
llvm-svn: 333510
|
| |
|
|
| |
llvm-svn: 333509
|
| |
|
|
|
|
| |
A future patch will remove the old masked intrinsics.
llvm-svn: 333508
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a recommit of r333390, which was reverted in r333395, because it
caused cyclic dependency when building shared library `LLVMDemangle.so`.
In this commit `ItaniumDemangler.cpp` was not changed.
The original commit message is below.
In r325551 many calls of malloc/calloc/realloc were replaces with calls of
their safe counterparts defined in the namespace llvm. There functions
generate crash if memory cannot be allocated, such behavior facilitates
handling of out of memory errors on Windows.
If the result of *alloc function were checked for success, the function was
not replaced with the safe variant. In these cases the calling function made
the error handling, like:
T *NewElts = static_cast<T*>(malloc(NewCapacity*sizeof(T)));
if (NewElts == nullptr)
report_bad_alloc_error("Allocation of SmallVector element failed.");
Actually knowledge about the function where OOM occurred is useless. Moreover
having a single entry point for OOM handling is convenient for investigation
of memory problems. This change removes custom OOM errors handling and
replaces them with calls to functions `llvm::safe_*alloc`.
Declarations of `safe_*alloc` are moved to a separate include file, to avoid
cyclic dependency in SmallVector.h
Differential Revision: https://reviews.llvm.org/D47440
llvm-svn: 333506
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D47512
llvm-svn: 333505
|
| |
|
|
|
|
|
|
|
|
| |
On Myriad RTEMS, we don't need to treat the main thread differently.
The existing thread hooks will do the right thing, so get rid of all
the unneeded special logic.
Differential Revision: https://reviews.llvm.org/D47502
llvm-svn: 333504
|
| |
|
|
|
|
|
|
|
| |
Reset shadow memory during exit. Also update a cut-and-paste comment,
and do some minor refactoring of InitializeShadowMemory.
Differential Revision: https://reviews.llvm.org/D47501
llvm-svn: 333503
|
| |
|
|
|
|
|
|
|
| |
The relocation for branch instructions in the dynamic loader of ExecutionEngine assumes branch instructions with R_PPC64_REL24 relocation type are only bl. However, with the tail call optimization, b instructions can be also used to jump into another function.
This patch makes the relocation to keep bits in the branch instruction other than the jump offset to avoid relocation rewrites a b instruction into bl.
Differential Revision: https://reviews.llvm.org/D47456
llvm-svn: 333502
|
| |
|
|
| |
llvm-svn: 333501
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The previous implementation misses an opportunity to apply NRVO (Named Return Value
Optimization) below. That discourages user to write early return code.
```
struct Foo {};
Foo f(bool b) {
if (b)
return Foo();
Foo oo;
return oo;
}
```
That is, we can/should apply RVO for a local variable if:
* It's directly returned by at least one return statement.
* And, all reachable return statements in its scope returns the variable directly.
While, the previous implementation disables the RVO in a scope if there are multiple return
statements that refers different variables.
On the new algorithm, local variables are in NRVO_Candidate state at first, and a return
statement changes it to NRVO_Disabled for all visible variables but the return statement refers.
Then, at the end of the function AST traversal, NRVO is enabled for variables in NRVO_Candidate
state and refers from at least one return statement.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: xbolva00, Quuxplusone, arthur.j.odwyer, cfe-commits
Differential Revision: https://reviews.llvm.org/D47067
llvm-svn: 333500
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D47500
llvm-svn: 333499
|
| |
|
|
|
|
|
|
|
|
| |
Codebases that need to be compatible with the Microsoft ABI can pass
this flag to avoid issues caused by the lack of a fixed ABI for
incomplete member pointers.
Differential Revision: https://reviews.llvm.org/D47503
llvm-svn: 333498
|
| |
|
|
|
|
|
|
| |
Mostly this fixes the names of all the 128-bit intrinsics to start with _mm_ instead of _mm128_ as is the convention and what the Intel docs say.
This also fixes the name of the bitshuffle intrinsics to say epi64 for 128 and 256 bit versions.
llvm-svn: 333497
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D47047
llvm-svn: 333496
|
| |
|
|
|
|
|
|
| |
On win32 we use lit's executeBuiltinEcho to implement the
echo command and this version only currently supports flags
that are separate.
llvm-svn: 333495
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D47398
llvm-svn: 333494
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loop-cleanup passes at the beginning of the loop pass pipeline, and
re-enqueue loops after even trivial unswitching.
This will allow us to much more consistently avoid simplifying code
while doing trivial unswitching. I've also added a test case that
specifically shows effective iteration using this technique.
I've unconditionally updated the new PM as that is always using the
SimpleLoopUnswitch pass, and I've made the pipeline changes for the old
PM conditional on using this new unswitch pass. I added a bunch of
comments to the loop pass pipeline in the old PM to make it more clear
what is going on when reviewing.
Hopefully this will unblock doing *partial* unswitching instead of just
full unswitching.
Differential Revision: https://reviews.llvm.org/D47408
llvm-svn: 333493
|
| |
|
|
| |
llvm-svn: 333492
|
| |
|
|
|
|
| |
Sorry for the breakage.
llvm-svn: 333491
|
| |
|
|
|
|
|
|
|
| |
Previously JITCompileCallbackManager only supported single threaded code. This
patch embeds a VSO (see include/llvm/ExecutionEngine/Orc/Core.h) in the callback
manager. The VSO ensures that the compile callback is only executed once and that
the resulting address cached for use by subsequent re-entries.
llvm-svn: 333490
|
| |
|
|
|
|
|
|
|
|
| |
mangling.
This helps especially when the collision is for a template specialization,
where the template arguments are not available from anywhere else in the
diagnostic, and are likely relevant to the problem.
llvm-svn: 333489
|
| |
|
|
|
|
|
| |
I missed adjusting a test under Misc in the last commit.
This patch updates that test.
llvm-svn: 333488
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Resolving fixup_riscv_call by assembler when the linker relaxation diabled
and the function and callsite within the same compile unit.
And also adding static_assert after Infos array declaration
to avoid missing any new fixup in MCFixupKindInfo in the future.
Differential Revision: https://reviews.llvm.org/D47126
llvm-svn: 333487
|
| |
|
|
| |
llvm-svn: 333486
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds the newly added `%sub` diagnostic modifier to cleanup repetition in the overload candidate diagnostics.
I think this should be good to go.
@rsmith: Some of the notes now emit `function template` where they only said `function` previously. It seems OK to me, but I would like your sign off on it.
Reviewers: rsmith, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D47101
llvm-svn: 333485
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds HIP toolchain to support HIP language mode. It includes:
Create specific compiler jobs for HIP.
Choose specific libraries for HIP.
With contribution from Greg Rodgers.
Differential Revision: https://reviews.llvm.org/D45212
llvm-svn: 333484
|
| |
|
|
|
|
|
|
|
|
| |
To support separate compile/link and linking across device IR in different source files,
a new HIP action builder is introduced. Basically it compiles/links host and device
code separately, and embed fat binary in host linking stage through linker script.
Differential Revision: https://reviews.llvm.org/D46476
llvm-svn: 333483
|
| |
|
|
|
|
|
| |
This is causing miscompiles and "definition with same mangled name as another
definition" errors.
llvm-svn: 333482
|
| |
|
|
|
|
|
|
| |
r333467 updated the symbols exported by libc++.so/dylib by changing
the ODR usage of __uncaught_exception/__uncaught_exceptions. This
should not be a breaking change.
llvm-svn: 333481
|
| |
|
|
|
|
|
|
| |
The comment only made sense a long time ago, when --thinlto-jobs was
tied with --lto-partitions. That was changed in r283817, but the test
wasn't updated at the same time. This patch does so.
llvm-svn: 333480
|
| |
|
|
|
|
|
| |
As discussed here: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058116.html
The tests fail on clang-5, as well as apple-clang-9. Mark them as such.
llvm-svn: 333479
|
| |
|
|
|
|
| |
See https://reviews.llvm.org/rL303907 for details about the bug.
llvm-svn: 333478
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Minor replacement. LLVM_ATTRIBUTE_USED was introduced to silence
a warning but using #ifndef NDEBUG makes more sense in this case.
Reviewers: dblaikie, fhahn, hsaito
Reviewed By: dblaikie
Differential Revision: https://reviews.llvm.org/D47498
llvm-svn: 333476
|
| |
|
|
|
|
|
|
| |
We only need the extractelt that corresponds to the register we're trying to insert back into. We can't guarantee the others haven't been optimized out depending on how those operands were produced.
So instead just look for an FR32/FR64 input and emit a COPY_TO_REGCLASS to VR128 in the output pattern. This matches what we do for ADD/SUB/MUL/DIV.
llvm-svn: 333473
|
| |
|
|
|
|
|
|
|
|
| |
Peter Collingbourne suggested moving the switch to the top of the
function, so that all the code that cares about the output section for a
symbol is in the same place.
Differential Revision: https://reviews.llvm.org/D47497
llvm-svn: 333472
|
| |
|
|
|
|
|
|
| |
-Warc-repeated-use-of-weak may trigger a segmentation fault when the Decl
being checked is outside of a function scope, leaving the current function
info pointer null. This adds a check before using the function info.
llvm-svn: 333471
|
| |
|
|
|
|
|
|
|
|
|
| |
While this value is initialized with the DefaultTargetTriple, it
can be later overriden using the -target flag so TargetTriple is
a more accurate name. This change also provides an accessor which
could be accessed from ToolChain implementations.
Differential Revision: https://reviews.llvm.org/D47357
llvm-svn: 333468
|
| |
|
|
|
|
| |
this. Thanks to Peter Klotz for calling my attention to this.
llvm-svn: 333467
|
| |
|
|
|
|
|
|
|
| |
Not strictly necessary, but makes the test more robust in case
we end up changing the defaults.
<rdar://problem/40622096>
llvm-svn: 333466
|
| |
|
|
|
|
|
|
| |
While I'm here, delete some dead code.
<rdar://problem/40622096>
llvm-svn: 333465
|
| |
|
|
| |
llvm-svn: 333464
|
| |
|
|
|
|
|
|
| |
that the operand names in the output pattern are always in 1, 2, 3 order since those are the operand names in the instruction.
The order should be controlled in the input pattern.
llvm-svn: 333463
|
| |
|
|
|
|
| |
The DEBUG macro was renamed LLVM_DEBUG.
llvm-svn: 333462
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
be both simpler and substantially more efficient.
Rather than use a hand-rolled iteration technique that isn't quite the
same as RPO, use the pre-built RPO loop body traversal utility.
Once visiting the loop body in RPO, we can assert that we visit defs
before uses reliably. When this is the case, the only need to iterate is
when simplifying a def that is used by a PHI node along a back-edge.
With this patch, the first pass over the loop body is just a complete
simplification of every instruction across the loop body. When we
encounter a use of a simplified instruction that stems from a PHI node
in the loop body that has already been visited (due to some cyclic CFG,
potentially the loop itself, or a nested loop, or unstructured control
flow), we recall that specific PHI node for the second iteration.
Nothing else needs to be preserved from iteration to iteration.
On the second and later iterations, only instructions known to have
simplified inputs are considered, each time starting from a set of PHIs
that had simplified inputs along the backedges.
Dead instructions are collected along the way, but deleted in a batch at
the end of each iteration making the iterations themselves substantially
simpler. This uses a new batch API for recursively deleting dead
instructions.
This alsa changes the routine to visit subloops. Because simplification
is fundamentally transitive, we may need to visit the entire loop body,
including subloops, to handle knock-on simplification.
I've added a basic test file that helps demonstrate that all of these
changes work. It includes both straight-forward loops with
simplifications as well as interesting PHI-structures, CFG-structures,
and a nested loop case.
Differential Revision: https://reviews.llvm.org/D47407
llvm-svn: 333461
|
| |
|
|
|
|
| |
The code could issue a truncate from a small type to larger type. We need to extend in that case instead.
llvm-svn: 333460
|
| |
|
|
|
|
|
|
|
|
| |
This should address some of the assert failures the fuzzer has been
finding such as:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6719
Differential Revision: https://reviews.llvm.org/D47086
llvm-svn: 333459
|
| |
|
|
| |
llvm-svn: 333458
|