This reverts commit 1bcdbd68616dc7f8debe126caafef7a7242a0e6b.
It's been reported that some bots are failing with this change with CMake
error like:
```
CMake Error at /b/s/w/ir/k/llvm-project/compiler-rt/cmake/config-ix.cmake:177 (message):
Unsupported architecture: arm64
Call Stack (most recent call first):
/b/s/w/ir/k/llvm-project/compiler-rt/cmake/config-ix.cmake:216 (get_target_flags_for_arch)
/b/s/w/ir/k/llvm-project/compiler-rt/test/tsan/CMakeLists.txt:78 (get_test_cflags_for_apple_platform)
```
I'm reverting the patch now to unbreak builds. I will investigate properly when time permits.
rdar://problem/50124489
llvm-svn: 359327
This temporary change tells us about all the places where the return
value of the INTERCEPT_FUNCTION macro is actually used. In the next
patch I will cleanup the macro and remove GetRealFuncAddress.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D61145
llvm-svn: 359325
Summary:
The use case here is to be able get the UUIDs of the modules that need
to be symbolicated so that external plugins can see them. This
information can be extracted from ASan reports if the `print_module_map`
ASan option is enabled. Currently printing of the module map is only
implemented on Darwin and so this is effectively a Darwin only feature
right now.
The module map hooks into symbolization using the new plugin
infrastructure. A new hook in `AsanSymbolizerPlugInProxy` (and in
`AsanSymbolizerPlugIn`) is also provided to allow external plugins to hook
into the module look up process. This will allow external plugins to
look up modules with knowledge of their UUID.
The new plug-in is currently stored in the `asan_symbolize.py` script.
We could potentially move this into a separate file in the future (to
reduce clutter) if we can come up with a policy for where to search for
plugins that should always get loaded.
rdar://problem/49476995
Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka
Subscribers: #sanitizers, llvm-commits
Tags: #llvm, #sanitizers
Differential Revision: https://reviews.llvm.org/D60531
llvm-svn: 359322
Add support for abs() to ConstantRange. This will allow to handle
SPF_ABS select flavor in LVI and will also come in handy as a
primitive for the srem implementation.
The implementation is slightly tricky, because a) abs of signed min
is signed min and b) sign-wrapped ranges may have an abs() that is
smaller than a full range, so we need to explicitly handle them.
Differential Revision: https://reviews.llvm.org/D61084
llvm-svn: 359321
The standard requires the following for the std::regex_constants::error_type
values: "The type error_type is an implementation-defined enumerated type."
The values of this enumerated type are not required to be non-zero.
This patch makes such checks in tests libc++-specific to let the tests
pass for other conforming implementations.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D61195
llvm-svn: 359320
The PPC vector cost model values for insert/extract element reflect older
processors that lacked vector insert/extract and move-to/move-from VSR
instructions. Update getVectorInstrCost to give appropriate values for when
the newer instructions are present.
Differential Revision: https://reviews.llvm.org/D60160
llvm-svn: 359313
In addition, fix and convert the two tests to yaml2obj based. This
allows us to delete two executables.
X86/weak.test: 'v' was not tested
X86/init-fini.test: symbol types of __bss_start _edata _end were wrong
GNU nm reports __init_array_start as 't', and __preinit_array_start as 'd'.
__init_array_start is 't' just because its section ".init_array" starts with ".init"
'd' makes more sense and allows us to drop the weird SHT_INIT_ARRAY rule.
So, change __init_array_start to 'd' instead.
llvm-svn: 359311
"DefineStd(Builder, "bpf", Opts)" generates the following three
macros:
bpf
__bpf
__bpf__
and the macro "bpf" is due to the fact that the target language
is C which allows GNU extensions.
The name "bpf" could be easily used as variable name or type
field name. For example, in current linux kernel, there are
four places where bpf is used as a field name. If the corresponding
types are included in bpf program, the compilation error will
occur.
This patch removed predefined macro "bpf" as well as "__bpf" which
is rarely used if used at all.
Signed-off-by: Yonghong Song <yhs@fb.com>
Differential Revision: https://reviews.llvm.org/D61173
llvm-svn: 359310
platforms.
The main problem here is that `-*-version_min=` was not being passed to
the compiler when building test cases. This can cause problems when
testing on devices running older OSs because Clang would previously
assume the minimum deployment target is the the latest OS in the SDK
which could be much newer than what the device is running.
Previously the generated value looked like this:
`-arch arm64 -isysroot
<path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk`
With this change it now looks like:
`-arch arm64 -stdlib=libc++ -miphoneos-version-min=8.0 -isysroot
<path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk`
This mirrors the setting of `config.target_cflags` on macOS.
This change is made for ASan, LibFuzzer, TSan, and UBSan.
To implement this a new `get_test_cflags_for_apple_platform()` function
has been added that when given an Apple platform name and architecture
returns a string containing the C compiler flags to use when building
tests. This also calls a new helper function `is_valid_apple_platform()`
that validates Apple platform names.
rdar://problem/50124489
Differential Revision: https://reviews.llvm.org/D58578
llvm-svn: 359305
Add a new lit-cpuid tool that detects CPU features used by some of
the tests, and use it to populate available_features in lit. For now,
this means that the test for MM/XMM register read will be run only
when the host CPU support SSE instruction set. However, this is going
to make it possible to introduce additional tests relying on AVX.
Differential Revision: https://reviews.llvm.org/D61073
llvm-svn: 359303
This encapsulates the section specific code inside the
corresponding writeSectionContent methods.
Making the code a bit more consistent.
llvm-svn: 359297
Create a matchBitOpReduction helper that checks for the pattern with any opcode.
First step towards reusing this code to recognize other scalar reduction patterns.
llvm-svn: 359296
The slow path (with at least one non US-ASCII) will be slower but that
doesn't matter.
Differential Revision: https://reviews.llvm.org/D61178
llvm-svn: 359294
As detailed on PR40758, Bobcat/Jaguar can perform vector immediate shifts on the same pipes as vector ANDs with the same latency - so it doesn't make sense to replace a shl+lshr with a shift+and pair as it requires an additional mask (with the extra constant pool, loading and register pressure costs).
Differential Revision: https://reviews.llvm.org/D61068
llvm-svn: 359293
A small step towards combining shuffles across vector sizes - this recognizes when a shuffle's operands are all extracted from the same larger source and tries to combine to an unary shuffle of that source instead. Fixes one of the test cases from PR34380.
Differential Revision: https://reviews.llvm.org/D60512
llvm-svn: 359292
This enables the pass to be used in the absence of
TargetTransformInfo. When the argument isn't passed, the factory
defaults to UninitializedAddressSpace and the flat address space is
obtained from the TargetTransformInfo as before this change. Existing
users won't have to change.
Patch by Kevin Petit.
Differential Revision: https://reviews.llvm.org/D60602
llvm-svn: 359290
Summary:
The new dwarf generator is pretty much a verbatim copy of the one in
PDB.
In order to write a pdb-independent test for it, I needed to write a
dummy "symbol resolver", which (together with the fact that I'll need
one more for breakpad-specific resolution logic) prompted me to create a
more simple interface for algorithms which replace or "resolve"
SymbolNodes. The resolving algorithms in NativePDB have been updated to
make use of that too.
I have removed a couple of NativePDB tests which weren't testing
anything pdb-specific and where the tested functionality was covered by
the new format-agnostic tests I have added.
Reviewers: amccarth, clayborg, aleksandr.urakov
Subscribers: aprantl, markmentovai, lldb-commits, jasonmolenda, JDevlieghere
Differential Revision: https://reviews.llvm.org/D61056
llvm-svn: 359288
The code was using the alignment of a pointer to the value, not the
alignment of the constant itself.
Maybe we got away with it so far because the pointer alignment is
fairly high, but we did end up under-aligning <16 x i8> vectors,
which was caught in the Chromium build after lld stopped over-aligning
the .rodata.cst16 section in r356428. (See crbug.com/953815)
Differential revision: https://reviews.llvm.org/D61124
llvm-svn: 359287
Contrary to MSVC, GCC/MinGW needs to have the dllexport attribute
on the template instantiation declaration, not on the definition.
Previously clang never marked explicit template instantiations as
dllexport in MinGW mode, if the instantiation had a previous
declaration, regardless of where the attribute was placed. This
makes Clang behave like GCC in this regard, and allows using the
same attribute form for both MinGW compilers.
This fixes PR40256.
Differential Revision: https://reviews.llvm.org/D61118
llvm-svn: 359285
Summary: We scrape the enclosing scopes from the source file, and use them in the query.
Reviewers: kadircet
Subscribers: ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61077
llvm-svn: 359284
This patch is more of a fix than a real improvement: in checkPostCall()
we should return immediately after finding the right call and handling
it. This both saves unnecessary processing and double-handling calls by
mistake.
Differential Revision: https://reviews.llvm.org/D61134
llvm-svn: 359283
When constrainRegClass is called if the constraining happens on a use the COPY
needs to be inserted before the instruction that contains the MachineOperand,
but if we are constraining a definition it actually needs to be added
after the instruction. In addition, the COPY needs to have its operands
flipped (in the use case we are copying from the old unconstrained register
to the new constrained register, while in the definition case we are copying
from the new constrained register that the instruction defines to the old
unconstrained register).
llvm-svn: 359282
Summary:
When we want to compare a ConstString against a string literal (or any other non-ConstString),
we currently have to explicitly turn the other string into a ConstString. This makes sense as
comparing ConstStrings against each other is only a fast pointer comparison.
However, currently we (rather incorrectly) use in several places in LLDB temporary ConstStrings when
we just want to compare a given ConstString against a hardcoded value, for example like this:
```
if (extension != ConstString(".oat") && extension != ConstString(".odex"))
```
Obviously this kind of defeats the point of ConstStrings. In the comparison above we would
construct two temporary ConstStrings every time we hit the given code. Constructing a
ConstString is relatively expensive: we need to go to the StringPool, take a read and possibly
an exclusive write-lock and then look up our temporary string in the string map of the pool.
So we do a lot of heavy work for essentially just comparing a <6 characters in two strings.
I initially wanted to just fix these issues by turning the temporary ConstString in static variables/
members, but that made the code much less readable. Instead I propose to add a new overload
for the ConstString comparison operator that takes a StringRef. This comparison operator directly
compares the ConstString content against the given StringRef without turning the StringRef into
a ConstString.
This means that the example above can look like this now:
```
if (extension != ".oat" && extension != ".odex")
```
It also no longer has to unlock/lock two locks and call multiple functions in other TUs for constructing
the temporary ConstString instances. Instead this should end up just being a direct string comparison
of the two given strings on most compilers.
This patch also directly updates all uses of temporary and short ConstStrings in LLDB to use this new
comparison operator. It also adds a some unit tests for the new and old comparison operator.
Reviewers: #lldb, JDevlieghere, espindola, amccarth
Reviewed By: JDevlieghere, amccarth
Subscribers: amccarth, clayborg, JDevlieghere, emaste, arichardson, MaskRay, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60667
llvm-svn: 359281
This is https://bugs.llvm.org//show_bug.cgi?id=38750.
If script references empty sections in LOADADDR/ADDR commands
.empty : { *(.empty ) }
.text : AT(LOADADDR (.empty) + SIZEOF (.empty)) { *(.text) }
then an empty section will be removed and LOADADDR/ADDR will evaluate to null.
It is not that user may expect from using of the generic script, what is a common case.
Differential revision: https://reviews.llvm.org/D54621
llvm-svn: 359279
Dan Liew