| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 276287
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is an other tentative to fix:
https://reviews.llvm.org/D22588
It's less clever, but should work.
Turn out there is not an easy way to write a portable print
for a pointer in lowercase without the prefix 0x.
Reviewers: rnk
Subscribers: llvm-commits, wang0109, kubabrecka, chrisha
Differential Revision: https://reviews.llvm.org/D22606
llvm-svn: 276286
|
| |
|
|
|
|
| |
As requested on D22509, I've pulled out the v8i16 extraction lowering as the SSE41 and pre-SSE41 implementations are effectively the same.
llvm-svn: 276285
|
| |
|
|
|
|
| |
No functionality change intended.
llvm-svn: 276284
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds InputSectionDescription command to represent
the input section declaration.
This leads to next cleanup:
SectionRule removed.
ScriptConfiguration::Sections mamber removed.
LinkerScript<ELFT>::getOutputSection() removed.
Differential revision: https://reviews.llvm.org/D22617
llvm-svn: 276283
|
| |
|
|
|
|
|
| |
The std::string is still constructed on demand. No functionality change
intended.
llvm-svn: 276282
|
| |
|
|
|
|
|
|
|
|
|
|
| |
As reported on PR26235, we don't currently make use of the VBROADCASTF128/VBROADCASTI128 instructions (or the AVX512 equivalents) to load+splat a 128-bit vector to both lanes of a 256-bit vector.
This patch enables lowering from subvector insertion/concatenation patterns and auto-upgrades the llvm.x86.avx.vbroadcastf128.pd.256 / llvm.x86.avx.vbroadcastf128.ps.256 intrinsics to match.
We could possibly investigate using VBROADCASTF128/VBROADCASTI128 to load repeated constants as well (similar to how we already do for scalar broadcasts).
Differential Revision: https://reviews.llvm.org/D22460
llvm-svn: 276281
|
| |
|
|
|
|
|
|
|
|
|
|
| |
symbol.
Reviewers: bkramer
Subscribers: ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D22567
llvm-svn: 276280
|
| |
|
|
|
|
|
|
|
|
| |
Patch broke ModuleDebugInfo test on the build bots (but not locally). Again.
svn revision: r276271
This reverts commit 9da8a1b05362bc96f2855fb32b5588b89407685d.
llvm-svn: 276279
|
| |
|
|
|
|
| |
No functionality change intended.
llvm-svn: 276278
|
| |
|
|
|
|
|
|
| |
This provides an elegant pattern to solve the "construct if not in map
already" problem we have many times in LLVM. Without try_emplace we
either have to rely on a sentinel value (nullptr) or do two lookups.
llvm-svn: 276277
|
| |
|
|
|
|
|
| |
Coincidentally this function maps to the C++17 try_emplace. Rename it
for consistentcy with C++17 std::map. NFC.
llvm-svn: 276276
|
| |
|
|
|
|
| |
This opens the way for having a different Piece type for EhInputSection.
llvm-svn: 276275
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: tstellarAMD, vpykhtin
Subscribers: arsenm, kzhuravl
Differential Revision: https://reviews.llvm.org/D22620
llvm-svn: 276274
|
| |
|
|
| |
llvm-svn: 276273
|
| |
|
|
| |
llvm-svn: 276272
|
| |
|
|
|
|
| |
Unreferenced nested structs and classes were omitted from the debug info. In DWARF, this was intentional, to avoid bloat. But for CodeView, we want this information to be consistent with what Microsoft tools would produce and expect.
llvm-svn: 276271
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces the actual compute code in the GPU kernels. To ensure
all values referenced from the statements in the GPU kernel are indeed available
we scan all ScopStmts in the GPU kernel for references to llvm::Values that
are not yet covered by already modeled outer loop iterators, parameters, or
array base pointers and also pass these additional llvm::Values to the
GPU kernel.
For arrays used in the GPU kernel we introduce a new ScopArrayInfo object, which
is referenced by the newly generated access functions within the GPU kernel and
which is used to help with code generation.
llvm-svn: 276270
|
| |
|
|
|
|
|
| |
This will be used by Polly GPGPU to determine the values that need to be
passed to GPU kernels.
llvm-svn: 276269
|
| |
|
|
|
|
|
|
|
| |
This is useful for external users using IslExprBuilder, in case they cannot
embed ScopArrayInfo data into their isl_ids, because the isl_ids either already
carry other information or the isl_ids have been created and their user pointers
cannot be updated any more.
llvm-svn: 276268
|
| |
|
|
|
|
|
|
|
| |
r275711 for "speedng up symbol version handling" was committed
by misunderstanding; the benchmark number was measured with
a debug build. The number with a release build didn't actually change.
This patch removes false optimizations added in that patch.
llvm-svn: 276267
|
| |
|
|
|
|
|
|
| |
The clearance calculation did not take into account registers defined as outputs or clobbers in inline assembly machine instructions because these register defs are implicit.
Differential Revision: http://reviews.llvm.org/D22580
llvm-svn: 276266
|
| |
|
|
|
|
|
| |
StringMap is designed to hold large values. No functionality change
intended.
llvm-svn: 276265
|
| |
|
|
| |
llvm-svn: 276264
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This ensures that no trivially dead code is generated. This is not only cleaner,
but also avoids troubles in case code is generated in a separate function and
some of this dead code contains references to values that are not available.
This issue may happen, in case the memory access functions have been updated
and old getelementptr instructions remain in the code. With normal Polly,
a test case is difficult to draft, but the upcoming GPU code generation can
possibly trigger such problems. We will later extend this dead-code elimination
to region and vector statements.
llvm-svn: 276263
|
| |
|
|
| |
llvm-svn: 276262
|
| |
|
|
|
|
|
| |
This change simplifies interaction between Writer and the linker script
because we can make needsInterpSection() a file-scope function.
llvm-svn: 276261
|
| |
|
|
| |
llvm-svn: 276260
|
| |
|
|
| |
llvm-svn: 276259
|
| |
|
|
|
|
| |
It didn't fix the problem on the buildbot. CAN_TARGET_mips64 is still true.
llvm-svn: 276258
|
| |
|
|
| |
llvm-svn: 276257
|
| |
|
|
|
|
|
|
| |
I think it's wiped out the build area and fully-reconfigured for the first time
since r268977. This seems to have caused Mips64 to become enabled when it wasn't
before because compiling with -mabi=64 succeeds but linking with -mabi=64 fails.
llvm-svn: 276256
|
| |
|
|
|
|
| |
sanitizers to disable explicitly too
llvm-svn: 276255
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for the fall (northern hemisphere) 2016 Darwin platforms to learn
about loaded images, instead of reading dyld internal data structures.
These new SPI don't exist on older releases, and new packets are
needed from debugserver to use them (those changes are already committed).
I had to change the minimum deployment target for debugserver in the xcode
project file to macOS 10.10 so that debugserver will use the
[[NSProcessInfo processInfo] operatingSystemVersion]
call in MachProcess::GetOSVersionNumbers to get the operarting system
version # -- this API is only available in macOS 10.10 and newer
("OS X Yosemite", released Oct 2014). If we have many people building
llvm.org lldb on older systems still, we can back off on this for the
llvm.org sources.
There should be no change in behavior with this commit, either to
older darwin systems or newer darwin systems.
For now the new DynamicLoader plugin is never activated - I'm forcing
the old plugin to be used in DynamicLoaderDarwin::UseDYLDSPI.
I'll remove that unconditional use of the old plugin soon, so the
newer plugin is used on the newest Darwin platforms.
<rdar://problem/25251243>
llvm-svn: 276254
|
| |
|
|
|
|
|
|
|
| |
Previously OutputSectionCommand::Filler was introduced, but unused.
Patch fixes that.
Differential revision: https://reviews.llvm.org/D22615
llvm-svn: 276253
|
| |
|
|
|
|
|
|
|
| |
language extensions.
These are used by libstdc++ <type_traits> for is_integral<__int128>.
Addresses http://llvm.org/pr23156.
llvm-svn: 276252
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to extraneous and missing dependencies and attempts to build on unsupported OSes
Summary:
This is a fixed-up version of D21612, to address failure identified post-commit.
Original commit description:
This patch implements the initialisation and patching routines for the XRay runtime, along with the necessary trampolines for function entry/exit handling. For now we only define the basic hooks for allowing an implementation to define a handler that gets run on function entry/exit. We expose a minimal API for controlling the behaviour of the runtime (patching, cleanup, and setting the handler to invoke when instrumenting).
Fixes include:
- Gating XRay build to only Linux x86_64 and with the right dependencies in case it is the only library being built
- Including <cstddef> to fix std::size_t issue
Reviewers: kcc, rnk, echristo
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D22611
llvm-svn: 276251
|
| |
|
|
|
|
|
|
|
|
| |
target throw an error if used on 32-bit target.
If these builtins are allowed to go through on a 32-bit target they will fire assertions in the backend.
Fixes PR28635.
llvm-svn: 276250
|
| |
|
|
|
|
|
|
| |
64-bit GPRs are available.
Usages of these intrinsics in a 32-bit build results in assertions in the backend.
llvm-svn: 276249
|
| |
|
|
|
|
|
| |
If we have optimization hints with agree with each other along different
paths, preserve them.
llvm-svn: 276248
|
| |
|
|
|
|
|
|
|
|
|
| |
It seems the order in which we generated memory accesses changed such that
the import of these updated memory accesses failed for the 'loop3' statement
in this test case. Unfortunately, the existing CHECK lines were not strict
enough to catch this. Hence, besides fixing the order of the memory access
lines we also ensure that the memory access changes are both clearly visibly
and well checked.
llvm-svn: 276247
|
| |
|
|
|
|
|
|
| |
This makes the structure of the code clearer and reduces the size of runOnScop.
We also adjust the coding style to the latest LLVM style guide.
llvm-svn: 276246
|
| |
|
|
|
|
|
|
| |
This makes the structure of the code clearer and reduces the size of runOnScop.
We also adjust the coding style to the latest LLVM style guide.
llvm-svn: 276245
|
| |
|
|
|
|
|
|
| |
This makes the structure of the code clearer and reduces the size of runOnScop.
We also adjust the coding style to the latest LLVM style guide.
llvm-svn: 276244
|
| |
|
|
|
|
|
|
|
|
|
| |
Approach uses LLVM-style RTTI for representing the linker script
commands in a form of tree for future simplification of parsing.
Core idea and code sample belongs to Rui Ueyama.
Differential revision: https://reviews.llvm.org/D22604
llvm-svn: 276243
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This can happen when emitting a local decl, which triggers
loading a decl imported from an AST file, which we then
hand to the AST consumer. Timer is not allowed to recurse
so an assertion fire. Keep a reference counter to avoid this
problem. LGTM'd by Richard Smith on IRC.
Differential Revision: https://reviews.llvm.org/D20748
llvm-svn: 276242
|
| |
|
|
|
|
| |
Also comment out a _LIBCPP_ASSERT that gcc4.9 was complaining about. Will revisit that later.
llvm-svn: 276241
|
| |
|
|
|
|
|
| |
We hoisted loads/stores without taking into account which can cause
miscompiles.
llvm-svn: 276240
|
| |
|
|
| |
llvm-svn: 276239
|
| |
|
|
|
|
| |
Reviewed as https://reviews.llvm.org/D21459
llvm-svn: 276238
|