The addresses of undefined symbols that make it into the final
executable (i.e. weak references to non-existent symbols) should
resolve to zero.
Also, make sure to not include function in the indirect function
table if they are not included in the output.
Differential Revision: https://reviews.llvm.org/D41839
llvm-svn: 322045
Add attribute target multiversioning to the release notes.
Additionally adds multiversioning support to the attribute
documentation for 'target'.
Differential Revision: https://reviews.llvm.org/D41837
llvm-svn: 322043
Currently LLVM's paralellForEach has a problem with reentracy.
That caused https://bugs.llvm.org/show_bug.cgi?id=35788 (lld somtimes
hangs while linking Ruby 2.4) because maybeCompress calls writeTo which
uses paralellForEach.
This patch is to avoid using paralellForEach to call maybeCompress
to workaround the issue.
llvm-svn: 322041
These tests started failing because we now properly convert
DefRange records to and from Yaml, but there were some old yaml
files that had incorrect record definitions generated by the
old buggy obj2yaml. Rather than try to re-generate the yaml files,
it's easier to just remove the records, and they weren't necessary
for the proper execution of the test anyway.
llvm-svn: 322040
Seems to have broken some tests since I first wrote this a while
back. Will reland after checking what went wrong with the tests.
This reverts commit 7023194c8d11a081fd01ed25308b3d60193c6a06.
llvm-svn: 322039
I'm going to convert these to 'icmp slt X, zeroinitializer' in clang's CGBuiltin.cpp, but the GCCBuiltin names need to be removed to do that.
llvm-svn: 322037
This patch makes the following changes to the schedule of instructions in the
prologue and epilogue.
The stack pointer update is moved down in the prologue so that the callee saves
do not have to wait for the update to happen.
Saving the lr is moved down in the prologue to hide the latency of the mflr.
The stack pointer is moved up in the epilogue so that restoring of the lr can
happen sooner.
The mtlr is moved up in the epilogue so that it is away form the blr at the end
of the epilogue. The latency of the mtlr can now be hidden by the loads of the
callee saved registers.
Differential Revision: https://reviews.llvm.org/D41737
llvm-svn: 322036
The body of the in scanRelocs is fairly big. This moves it to its own
function.
It is not a big readability win by itself, but should help further
refactoring.
llvm-svn: 322035
If the make program isn't in the path, the native configure will fail.
Pass CMAKE_MAKE_PROGRAM to the native configure explicitly to remedy
this, similar to what's already done for external project configuration.
Explicitly set CMAKE_MAKE_PROGRAM before the user flags so that they can
override it for the native build if they desire (though I can't fathom
why that would be useful).
llvm-svn: 322032
The problem was that our Obj -> Yaml dumper had not been taught
to handle certain types of records. This meant that when I
generated the test input files, the records were still there but
none of its fields were filled out. So when it did the
Yaml -> Obj conversion as part of the test, it generated records
with garbage in them.
The patch here fixes the Obj <-> Yaml converter, and additionally
updates the test file with fresh Yaml generated by the fixed
converter.
llvm-svn: 322029
GCC's attribute 'target', in addition to being an optimization hint,
also allows function multiversioning. We currently have the former
implemented, this is the latter's implementation.
This works by enabling functions with the same name/signature to coexist,
so that they can all be emitted. Multiversion state is stored in the
FunctionDecl itself, and SemaDecl manages the definitions.
Note that it ends up having to permit redefinition of functions so
that they can all be emitted. Additionally, all versions of the function
must be emitted, so this also manages that.
Note that this includes some additional rules that GCC does not, since
defining something as a MultiVersion function after a usage has been made illegal.
The only 'history rewriting' that happens is if a function is emitted before
it has been converted to a multiversion'ed function, at which point its name
needs to be changed.
Function templates and virtual functions are NOT yet supported (not supported
in GCC either).
Additionally, constructors/destructors are disallowed, but the former is
planned.
llvm-svn: 322028
- Fix incorrect wording in various intrinsic descriptions. Previously the descriptions used "low-order" and "high-order" when the intended meaning was "even-indexed" and "odd-indexed".
- Fix a few typos and errors found during review.
- Restore new line endings.
This patch was made by Craig Flores
llvm-svn: 322027
It was being set but never used, and its value is only ever needed
locally in lld::coff::link.
Differential Revision: https://reviews.llvm.org/D41814
llvm-svn: 322026
This is not quite NFC: we don't perform the usual arithmetic conversions unless
we have an operand of arithmetic or enumeration type any more. This matches the
standard rule, but actually has no effect other than to marginally improve our
diagnostics for the non-arithmetic, non-enumeration cases (by not performing
integral promotions on one operand if the other is a pointer).
llvm-svn: 322024
Summary:
The flag has been deprecated, and is becoming invalid in the latest
MDK.
Reviewers: jyknight
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41713
llvm-svn: 322023
Add test/DebugInfo/MIR/Mips/lit.local.cfg so no tests are run if Mips is
not a supported target.
This should resolve buildbot failures seen after r322015.
llvm-svn: 322020
Summary: Some info about supported features of OpenMP 4.5-5.0.
Reviewers: hfinkel, rsmith
Subscribers: kkwli0, Hahnfeld, cfe-commits
Differential Revision: https://reviews.llvm.org/D39457
llvm-svn: 322018
Summary:
DC may sometimes be NULL and getContainerInfo(DC, Container) will dereference a null pointer.
Default template arguments (the following example and many test files in https://github.com/nlohmann/json)
may cause null pointer dereference.
```c++
template <typename>
struct actor;
template <template <typename> class Actor = actor>
struct terminal;
```
In tools/libclang/CXIndexDataConsumer.cpp#L203
handleReference(ND, Loc, Cursor,
dyn_cast_or_null<NamedDecl>(ASTNode.Parent),
ASTNode.ContainerDC, ASTNode.OrigE, Kind);
`dyn_cast_or_null<NamedDecl>(ASTNode.Parent)` is somehow a null pointer and in tools/libclang/CXIndexDataConsumer.cpp:935
ContainerInfo Container;
getContainerInfo(DC, Container);
The null DC is casted `ContInfo.cursor = getCursor(cast<Decl>(DC));` and SIGSEGV.
```
See discussions in https://github.com/jacobdufault/cquery/issues/219https://github.com/jacobdufault/cquery/issues/192
Reviewers: akyrtzi, sammccall, yvvan
Reviewed By: sammccall
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D41575
llvm-svn: 322017
The last iterator of MBB should be recognized as MBB.end() not as
MBB.instr_end() which could return bundled instruction that is not iterable
with basic iterator.
Patch by Nikola Prica.
Differential Revision: https://reviews.llvm.org/D41626
llvm-svn: 322015
This patch was part of:
https://reviews.llvm.org/D41338
...but we can expose the bug in IR via constant propagation
as shown in the test. Unless the triple includes 'linux', we
should not fold these because the functions don't exist on
other platforms (yet?).
llvm-svn: 322010
The new test fails on the Hexagon bot. Reverting while I investigate.
This reverts https://reviews.llvm.org/rL322005
This reverts commit b7e0026b4385180c378edc658ec91a39566f2942.
llvm-svn: 322008
This is an attempt of fixing PR35807.
Due to the non-standard definition of dominance in LLVM, where uses in
unreachable blocks are dominated by anything, you can have, in an
unreachable block:
%patatino = OP1 %patatino, CONSTANT
When `SimplifyInstruction` receives a PHI where an incoming value is of
the aforementioned form, in some cases, loops indefinitely.
What I propose here instead is keeping track of the incoming values
from unreachable blocks, and replacing them with undef. It fixes this
case, and it seems to be good regardless (even if we can't prove that
the value is constant, as it's coming from an unreachable block, we
can ignore it).
Differential Revision: https://reviews.llvm.org/D41812
llvm-svn: 322006
Adds option /guard:cf to clang-cl and -cfguard to cc1 to emit function IDs
of functions that have their address taken into a section named .gfids$y for
compatibility with Microsoft's Control Flow Guard feature.
Differential Revision: https://reviews.llvm.org/D40531
llvm-svn: 322005
This patch improves diagnostic for case when mapped instruction
does not contain a field listed under RowFields.
Differential Revision: https://reviews.llvm.org/D41778
llvm-svn: 322004
Summary:
Fix DanglingHandleCheck to handle the final implementation of std::string and std::string_view.
These use a conversion operator instead of a conversion constructor.
Reviewers: hokein
Subscribers: klimek, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D41779
llvm-svn: 322002
There is precedence for factorization transforms in instcombine for FP ops with fast-math.
We also have similar logic in foldSPFofSPF().
It would take more work to add this to reassociate because that's specialized for binops,
and min/max are not binops (or even single instructions). Also, I don't have evidence that
larger min/max trees than this exist in real code, but if we find that's true, we might
want to reorganize where/how we do this optimization.
In the motivating example from https://bugs.llvm.org/show_bug.cgi?id=35717 , we have:
int test(int xc, int xm, int xy) {
int xk;
if (xc < xm)
xk = xc < xy ? xc : xy;
else
xk = xm < xy ? xm : xy;
return xk;
}
This patch solves that problem because we recognize more min/max patterns after rL321672
https://rise4fun.com/Alive/Qjnehttps://rise4fun.com/Alive/3yg
Differential Revision: https://reviews.llvm.org/D41603
llvm-svn: 321998
Summary:
Fixes the bug with incorrect handling of InsertValue|InsertElement
instrucions in SLP vectorizer. Currently, we may use incorrect
ExtractElement instructions as the operands of the original
InsertValue|InsertElement instructions.
Reviewers: mkuper, hfinkel, RKSimon, spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D41767
llvm-svn: 321994
Sam Clegg