Mac OS X 10.11, El Capitan, released c. Oct 2015) I conditionalized
the use of the framework on "if sdk == macosx 10.11". But since
macOS 10.12 has shipped this year, the framework was no longer being
built in. I can either start listing every OS 10.11 and newer, or
remove the version check.
This will break building lldb with xcodebuild / Xcode for people
running Mac OS X 10.10 or older. If so, I'll back this change out.
I'm not sure if we have many people working on macs running the
older OSes on their build systems.
<rdar://problem/30159130>
llvm-svn: 293742
Contrary to the comment, DeclContext intends to guarantee that the lookup
results for a particular name will be stable across non-AST-mutating
operations, so a copy here should not be necessary. Further, if a copy *is*
necessary, the other four instances of this pattern within this file would also
be wrong, and we have no evidence of any problems with them; if this change
unearths problems, we should fix all the instances of this pattern.
llvm-svn: 293740
This feature enables the fusion of such operations on Cortex A57, as
recommended in its Software Optimisation Guide, sections 4.14 and 4.15.
Differential revision: https://reviews.llvm.org/D28698
llvm-svn: 293739
This feature enables the fusion of such operations on Cortex A57, as
recommended in its Software Optimisation Guide, section 4.13, and on Exynos
M1.
Differential revision: https://reviews.llvm.org/D28491
llvm-svn: 293738
This patch moves the class for scheduling adjacent instructions,
MacroFusion, to the target.
In AArch64, it also expands the fusion to all instructions pairs in a
scheduling block, beyond just among the predecessors of the branch at the
end.
Differential revision: https://reviews.llvm.org/D28489
llvm-svn: 293737
Summary:
isSuitableMemoryOp method is repsonsible for verification
that instruction is a candidate to use in implicit null check.
Additionally it checks that base register is not re-defined before.
In case base has been re-defined it just returns false and lookup
is continued while any suitable instruction will not succeed this check
as well. This results in redundant further operations.
So when we found that base register has been re-defined we just
stop.
Patch by Serguei Katkov!
Reviewers: reames, sanjoy
Reviewed By: sanjoy
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29119
llvm-svn: 293736
clang-cl would evaluate the arguments right-to-left (see PR), and for
non-Windows targets I suppose we only got it because we were already
emitting left-to-right in CodeGenFunction::EmitCallArgs.
Differential Revision: https://reviews.llvm.org/D29350
llvm-svn: 293732
After this commint, we can include sancov_flags.h and refer to
__sancov_default_options without requiring the namespace prefix.
Differential Revision: https://reviews.llvm.org/D29167
llvm-svn: 293731
SplitEditor::defFromParent() can create a register copy.
If register is a tuple of other registers and not all lanes are used
a copy will be done on a full tuple regardless. Later register unit
for an unused lane will be considered free and another overlapping
register tuple can be assigned to a different value even though first
register is live at that point. That is because interference only look at
liveness info, while full register copy clobbers all lanes, even unused.
This patch fixes copy to only cover used lanes.
Differential Revision: https://reviews.llvm.org/D29105
llvm-svn: 293728
This is the patch upstreaming the plugins part of libomptarget (CUDA, generic-elf-64).
Differential Revision: https://reviews.llvm.org/D14253
llvm-svn: 293724
Summary:
This change implements the instrumentation map loading library which can
understand both YAML-defined instrumentation maps, and ELF 64-bit object
files that have the XRay instrumentation map section. We break it out
into a library on its own to allow for other applications to deal with
the XRay instrumentation map defined in XRay-instrumented binaries.
This type provides both raw access to the logical representation of the
instrumentation map entries as well as higher level functions for
converting a function ID into a function address.
At this point we only support ELF64 binaries and YAML-defined XRay
instrumentation maps. Future changes should extend this to support
32-bit ELF binaries, as well as other binary formats (like MachO).
As part of this change we also migrate all uses of the extraction logic
that used to be defined in tools/llvm-xray/ to use this new type and
interface for loading from files. We also remove the flag from the
`llvm-xray` tool that required users to specify the type of the
instrumentation map file being provided to instead make the library
auto-detect the file type.
Reviewers: dblaikie
Subscribers: mgorny, varno, llvm-commits
Differential Revision: https://reviews.llvm.org/D29319
llvm-svn: 293721
When choosing the best successor for a block, ordinarily we would have preferred
a block that preserves the CFG unless there is a strong probability the other
direction. For small blocks that can be duplicated we now skip that requirement
as well, subject to some simple frequency calculations.
Differential Revision: https://reviews.llvm.org/D28583
llvm-svn: 293716
Summary:
Problem:
There are three filelds in the ELF header - e_phnum, e_shnum, and e_shstrndx -
that could be bigger than 64K and therefore do not fit in 16 bits reserved for
them in the header. If this happens, pretty often there is a special section at
index 0 which contains their real values for these fields in the section header
in the fields sh_info, sh_size, and sh_link respectively.
Fix:
- Rename original fields in the header declaration. We want to have them around
just in case.
- Reintroduce these fields as 32-bit members at the end of the header. By default
they are initialized from the header in Parse() method.
- In Parse(), detect the situation when the header might have been extended into
section info #0 and try to read it from the same data source.
- ObjectFileELF::GetModuleSpecifications accesses some of these fields but the
original parse uses too small data source. Re-parse the header if necessary
using bigger data source.
- ProcessElfCore::CreateInstance uses header with potentially sentinel values,
but it does not access these fields, so a comment here is enough.
Reviewers: labath
Reviewed By: labath
Subscribers: davidb, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D29095
Author: Eugene Birukov <eugenebi@hotmail.com>
llvm-svn: 293714
x*rsqrt(x) returns NaN for x == 0, whereas 1/rsqrt(x) returns 0, as
desired.
Verified that the particular nvptx approximate instructions here do in
fact return 0 for x = 0.
llvm-svn: 293713
We ignore `__ubsan_handle_dynamic_type_cache_miss*` symbols when
`SANITIZER_CAN_USE_CXXABI` is true. Because they are included in the
library but they are not included in the interface lists.
llvm-svn: 293711
The test was failing because we export the functions: "__sanitizer_mz*" but they
are not included in the general interface lists.
Also, weak undefined symbols are tagged with U by `nm -g` on Darwin.
Differential Revision: https://reviews.llvm.org/D29345
llvm-svn: 293710
Technically, this is actually changes the expression and the original
assert was "wrong", but since the conjunction is with true, it doesn't
matter in this case.
llvm-svn: 293709
Summary:
This patch does two things. First it updates all the ABI plugins with accurate dependencies, and second it adds a tracking mechanism for add_lldb_library to denote plugin libraries, allowing us to build up a list of all the configured plugins.
This list of generated plugins will be used during generating liblldb so that we can link all the plugins into the library.
If this patch looks good I will update all the other plugins in subsequent patches.
Reviewers: labath, zturner
Subscribers: nemanjai, mgorny, lldb-commits, jgosnell
Differential Revision: https://reviews.llvm.org/D29348
llvm-svn: 293696
The Module::WithCodegen flag was only being set when the module was
parsed from a ModuleMap. Instead set it late, in the ASTWriter to match
the layer where the MODULAR_CODEGEN_DECLs list is determined (the
WithCodegen flag essentially means "are this module's decls in
MODULAR_CODEGEN_DECLs").
When simultaneous emission of AST file and modular object is implemented
this may need to change - the Module::WithCodegen flag will need to be
set earlier, and ideally the MODULAR_CODEGEN_DECLs gathering will
consult this flag (that's not possible right now since Decls destined
for an AST File don't have a Module - only if they're /read/ from a
Module is that true - I expect that would need to change as well).
llvm-svn: 293692
Jason Molenda