| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 284207
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch implements the library side of P0035R4. The implementation is thanks to @rsmith.
In addition to the C++17 implementation, the library implementation can be explicitly turned on using `-faligned-allocation` in all dialects.
Reviewers: mclow.lists, rsmith
Subscribers: rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D25591
llvm-svn: 284206
|
| |
|
|
| |
llvm-svn: 284205
|
| |
|
|
|
|
|
|
| |
vectors are less than half of the output vector size.
This will be needed by a future commit to support sign/zero extending from v8i8 to v8i64 which requires a sign/zero_extend_vector_inreg to be created which requires v8i8 to be concatenated upto v64i8 and goes through this code.
llvm-svn: 284204
|
| |
|
|
|
|
|
| |
sink the current behavior into the callers and sink
TargetMachine::getNameWithPrefix into TargetMachine::getSymbol.
llvm-svn: 284203
|
| |
|
|
|
|
| |
readability a bit.
llvm-svn: 284202
|
| |
|
|
| |
llvm-svn: 284201
|
| |
|
|
| |
llvm-svn: 284200
|
| |
|
|
| |
llvm-svn: 284199
|
| |
|
|
| |
llvm-svn: 284198
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D25563
llvm-svn: 284197
|
| |
|
|
|
|
|
|
| |
and global address space variables
Differential Revision: https://reviews.llvm.org/D25562
llvm-svn: 284196
|
| |
|
|
|
|
|
|
| |
appropriate relocations
Differential Revision: https://reviews.llvm.org/D25548
llvm-svn: 284195
|
| |
|
|
| |
llvm-svn: 284194
|
| |
|
|
|
|
|
| |
These functions were removed from the dylib sometime between the 3.9 release
and now. This patch manually exports them to re-gain ABI compatibility.
llvm-svn: 284193
|
| |
|
|
| |
llvm-svn: 284192
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added relocation names:
- R_AMDGPU_GOTPCREL32_LO
- R_AMDGPU_GOTPCREL32_HI
- R_AMDGPU_REL32_LO
- R_AMDGPU_REL32_HI
AMDGPU isa only supports 32-bit immediates. In order to access 64-bit address we need to generate 32-bit lo/hi relocations, and do the right math (separate patch). Currently we only generate one 32 bit relocation for lower bits for each access, losing higher bits. Hence we need relocations listed above.
Differential Revision: https://reviews.llvm.org/D25546
llvm-svn: 284191
|
| |
|
|
|
|
| |
This allows to use llvm:cl::opt without `using namespace llvm;`
llvm-svn: 284190
|
| |
|
|
| |
llvm-svn: 284189
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The primary reason for this patch is to add the OS X ABI lists for 3.9 and
ToT.
However while working on that I discovered that we incorrectly
exported the libc++abi symbols. Previously we had chosen the wrong CMake
configuration path and that caused us to re-export the c++abi binary instead
of using the symbol lists.
llvm-svn: 284188
|
| |
|
|
| |
llvm-svn: 284187
|
| |
|
|
| |
llvm-svn: 284186
|
| |
|
|
| |
llvm-svn: 284185
|
| |
|
|
|
|
| |
argument, in order to correctly instantiate the initializer.
llvm-svn: 284184
|
| |
|
|
| |
llvm-svn: 284183
|
| |
|
|
| |
llvm-svn: 284182
|
| |
|
|
| |
llvm-svn: 284181
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This will be used by ThinLTO to set the amount of backend
parallelism, which performs better when restricted to the number
of physical cores (on X86 at least, where getHostNumPhysicalCores is
currently defined). If not available this falls back to
thread::hardware_concurrency.
Note I didn't add to the thread class since that is a typedef to
std::thread where available.
Reviewers: mehdi_amini
Subscribers: beanz, llvm-commits, mgorny
Differential Revision: https://reviews.llvm.org/D25585
llvm-svn: 284180
|
| |
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D25522
Patch written by Aditya Kumar.
llvm-svn: 284179
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change depends on D23986 which adds tail call-specific sleds. For
now we treat them first as normal exits, and in the future leave room
for implementing this as a different kind of log entry.
The reason for deferring the change is so that we can keep the naive
logging implementation more accurate without additional complexity for
reading the log. The accuracy is gained in effectively interpreting call
stacks like:
A()
B()
C()
Which when tail-call merged will end up not having any exit entries for
A() nor B(), but effectively in turn can be reasoned about as:
A()
B()
C()
Although we lose the fact that A() had called B() then had called C()
with the naive approach, a later iteration that adds the explicit tail
call entries would be a change in the log format and thus necessitate a
version change for the header. We can do this later to have a chance at
releasing some tools (in D21987) that are able to handle the naive log
format, then support higher version numbers of the log format too.
Reviewers: echristo, kcc, rSerge, majnemer
Subscribers: mehdi_amini, llvm-commits, dberris
Differential Revision: https://reviews.llvm.org/D23988
llvm-svn: 284178
|
| |
|
|
| |
llvm-svn: 284177
|
| |
|
|
|
|
|
|
|
| |
compiles without -fmodules-local-submodule-visibility. Original commit message:
[modules] When merging one definition into another, propagate the list of
re-exporting modules from the discarded definition to the retained definition.
llvm-svn: 284176
|
| |
|
|
|
|
|
| |
Windows itanium is identical to MSVC when dealing with everything but C++.
Lower the math routines into msvcrt rather than compiler-rt.
llvm-svn: 284175
|
| |
|
|
|
|
|
|
|
|
|
| |
The backtrace on the bot does not give me any indication what is wrong.
The test case interestingly passes in stage2 of the build.
I don't have a way of debugging this.
Disable the test on windows and hope if there is truly a bug in the code that
was causing we will eventually run into this on other platforms.
llvm-svn: 284174
|
| |
|
|
|
|
|
| |
Windows itanium is equivalent to MSVC except in C++ mode. Ensure that the
promote the 32-bit floating point operations to their 64-bit equivalences.
llvm-svn: 284173
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Previously global 64-bit versions of _Interlocked functions broke buildbots on i386, so now I'm adding them as builtins for x86-64 and ARM only (should they be also on AArch64? I had problems with testing it for AArch64, so I left it)
Reviewers: hans, majnemer, mstorsjo, rnk
Subscribers: cfe-commits, aemerson
Differential Revision: https://reviews.llvm.org/D25576
llvm-svn: 284172
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
LeakSanitizer does not work with ptrace but currently it
will print warnings (only under verbosity=1) and then proceed
to print tons of false reports.
This patch makes lsan fail hard under ptrace with a verbose message.
https://github.com/google/sanitizers/issues/728
Reviewers: eugenis, vitalybuka, aizatsky
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D25538
llvm-svn: 284171
|
| |
|
|
| |
llvm-svn: 284170
|
| |
|
|
| |
llvm-svn: 284169
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would fail to synthesise a __start_ or __stop_ symbol if
there existed a definition in a DSO. Instead, we would try to link against
the DSO definition. This became possible after D23552 when linking against
lld-produced DSOs but could in principle also occur when linking against
DSOs produced by other linkers.
Not only does it seem more likely that a user would expect the resolved
definition to be local to the executable, but if a __start_ or __stop_
symbol was synthesised by the linker, it is effectively impossible to link
against correctly from a non-PIC executable in a read-only section. Neither
a PLT nor a copy relocation would give us the right semantics here. The only
way the link could succeed is if the executable provided its own synthetic
definition of the symbol.
The fix is to also synthesise the definition if the only definition comes
from a DSO. Since this is what the addOptionalSynthetic function does,
switch to using that function.
Fixes PR30680.
Differential Revision: https://reviews.llvm.org/D25544
llvm-svn: 284168
|
| |
|
|
| |
llvm-svn: 284167
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The class DataflowWorklist internally maintains a sorted list of pointers to CFGBlock
and the method enqueuePredecessors has to call sortWorklist to maintain the invariant.
The implementation based on vector + sort works well for small sizes
but gets infeasible for relatively large sizes. In particular the issue takes place
for some cryptographic libraries which use code generation.
The diff replaces vector + sort with priority queue.
For one of the implementations of AES this patch reduces
the time for analysis from 204 seconds to 8 seconds.
Test plan: make -j8 check-clang
Differential revision: https://reviews.llvm.org/D25503
llvm-svn: 284166
|
| |
|
|
| |
llvm-svn: 284165
|
| |
|
|
|
|
| |
std::function. These functions never worked, and as far as I know, no one ever called them.
llvm-svn: 284164
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This operation is promoted the same way was ISD::BSWAP. This will
prevent a regression in test/Target/AMDGOU/bitreverse.ll when i16
support is implemented.
Reviewers: bogner, hfinkel
Subscribers: hfinkel, wdng, llvm-commits
Differential Revision: https://reviews.llvm.org/D25202
llvm-svn: 284163
|
| |
|
|
| |
llvm-svn: 284162
|
| |
|
|
|
|
|
|
|
|
|
|
| |
the X86 subdirectory. Original commit message:
Requires a valid TargetMachine to be passed to the SafeStack pass.
Patch by Michael LeMay
Differential revision: http://reviews.llvm.org/D24896
llvm-svn: 284161
|
| |
|
|
|
|
|
|
|
| |
This option indicates copy relocations support is available from the linker
when building as PIE and allows accesses to extern globals to avoid the GOT.
Differential Revision: https://reviews.llvm.org/D24849
llvm-svn: 284160
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25571
llvm-svn: 284159
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Emitting deferred diagnostics during codegen was a hack. It did work,
but usability was poor, both for us as compiler devs and for users. We
don't codegen if there are any sema errors, so for users this meant that
they wouldn't see deferred errors if there were any non-deferred errors.
For devs, this meant that we had to carefully split up our tests so that
when we tested deferred errors, we didn't emit any non-deferred errors.
This change moves checking for deferred errors into Sema. See the big
comment in SemaCUDA.cpp for an overview of the idea.
This checking adds overhead to compilation, because we have to maintain
a partial call graph. As a result, this change makes deferred errors a
CUDA-only concept (whereas before they were a general concept). If
anyone else wants to use this framework for something other than CUDA,
we can generalize at that time.
This patch makes the minimal set of test changes -- after this lands,
I'll go back through and do a cleanup of the tests that we no longer
have to split up.
Reviewers: rnk
Subscribers: cfe-commits, rsmith, tra
Differential Revision: https://reviews.llvm.org/D25541
llvm-svn: 284158
|