llvm-svn: 374272

Summary:
The Transformer library has been growing inside of
lib/Tooling/Refactoring. However, it's not really related to anything else in
that directory. This revision moves all Transformer-related files into their own
include & lib directories.  A followup revision will (temporarily) add
forwarding headers to help any users migrate their code to the new location.

Reviewers: gribozavr

Subscribers: mgorny, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D68637

llvm-svn: 374271

llvm-svn: 374270

This reverts r374268 (git commit c34385d0)

I think I reverted this by mistake, so I'm relanding it. While my bisect
found this revision, I think the crashes I'm seeing locally must be
environmental. Maybe the version of clang I'm using miscompiles tot
clang.

llvm-svn: 374269

This reverts r374200 (git commit fd18e946)

Causes crashes just compiling `int main() {}` on my machine.

llvm-svn: 374268

Summary:
Visual Studio doesn't like it while stepping. It kicks you out of the
source view of the file being stepped through and tries to fall back to
the disassembly view.

Fixes PR43530

The fix is incomplete, because it's possible to have a basic block with
no source locations at all. In this case, we don't emit a .cv_loc, but
that will result in wrong stepping behavior in the debugger if the
layout predecessor of the location-less BB has an unrelated source
location. We could try harder to find a valid location that dominates or
post-dominates the current BB, but in general it's a dataflow problem,
and one still might not exist. I left a FIXME about this.

As an alternative, we might want to consider having the middle-end check
if its emitting codeview and get it to stop using line zero.

Reviewers: akhuang

Subscribers: hiraditya, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D68747

llvm-svn: 374267

This allows users to explicitly request relative paths with
`-fdebug-compilation-dir .`.

Fixes PR43614

Reviewers: vsk, arphaman

Differential Revision: https://reviews.llvm.org/D68733

llvm-svn: 374266

Dereferences with addresses above the 48-bit hardware addressable range
produce "invalid instruction" (instead of "invalid access") hardware
exceptions (there is no hardware address decoding logic for those bits),
and the address provided by this exception is the address of the
instruction (not the faulting address).  The kernel maps the "invalid
instruction" to SEGV, but fails to provide the real fault address.

Because of this ASan lies and says that those cases are null
dereferences.  This downgrades the severity of a found bug in terms of
security.  In the ASan signal handler, we can not provide the real
faulting address, but at least we can try not to lie.

rdar://50366151

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D68676

llvm-svn: 374265

    
debugserver had been using an instruction that would work
for armv7 or aarch64 processes, but we don't have armv7 code
running on arm64 devices any more so this is unnecessary.

<rdar://problem/56133118>

llvm-svn: 374264

CUDA/HIP program may be compiled with -fopenmp. In this case, -fopenmp is only passed to host compilation
to take advantages of multi-threads computation.

CUDA/HIP and OpenMP both use Sema::DeviceCallGraph to store functions to be analyzed and remove them
once they decide the function is sure to be emitted. CUDA/HIP and OpenMP have different functions to determine
if a function is sure to be emitted.

To check host/device correctly for CUDA/HIP when -fopenmp is enabled, there needs a unified logic to determine
whether a function is to be emitted. The logic needs to be aware of both CUDA and OpenMP logic.

Differential Revision: https://reviews.llvm.org/D67837

llvm-svn: 374263

The test needed some updates to run using a different UI toolkit
and with a different libMTC, but it should run fine on a device.

llvm-svn: 374262

As background, starting in D66309, I'm working on support unordered atomics analogous to volatile flags on normal LoadSDNode/StoreSDNodes for X86.

As part of that, I spent some time going through usages of LoadSDNode and StoreSDNode looking for cases where we might have missed a volatility check or need an atomic check. I couldn't find any cases that clearly miscompile - i.e. no test cases - but a couple of pieces in code loop suspicious though I can't figure out how to exercise them.

This patch adds defensive checks and asserts in the places my manual audit found. If anyone has any ideas on how to either a) disprove any of the checks, or b) hit the bug they might be fixing, I welcome suggestions.

Differential Revision: https://reviews.llvm.org/D68419

llvm-svn: 374261

llvm-svn: 374260

llvm-svn: 374259

Summary: Go now uses __sanitizer_on_print instead.

Reviewers: vitalybuka, dvyukov

Reviewed By: vitalybuka

Subscribers: llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D68621

llvm-svn: 374258

In a future patch, this will help cleanup m0 handling.

The register coalescer handles copies from a register that
materializes an immediate, but doesn't handle move immediates
itself. The virtual register uses will often be allocated to the same
register, so there end up being no real copy.

llvm-svn: 374257

This old test used a completely hand-rolled Makefile. Modernize so that
it's able to cross-compile. And XFAIL the test as it fails on embedded
targets...

llvm-svn: 374256

This was ignoring the register bank of the input pointer, and
isUniformMMO seems overly aggressive.

This will now conservatively assume a VGPR in cases where the incoming
bank hasn't been determined yet (i.e. is from a loop phi).

llvm-svn: 374255

llvm-svn: 374254

llvm-svn: 374253

Turn it into a G_CONCAT_VECTORS of G_BUILD_VECTOR.

llvm-svn: 374252

When building an executable and a shared library at the same time (yes,
Makefile.rules is setup to do this!) the executable was not codesigned.

llvm-svn: 374251

Summary: Fixes issue like D68719

Reviewers: tatyana-krasnukha

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D68728

llvm-svn: 374250

llvm-svn: 374249

* Silence unused-local-typedef warnings: `map.cons/assign_initializer_list.pass.cpp` (and the `set.cons` variant) uses a local typedef only within `LIBCPP_ASSERT`s, so clang diagnoses it as unused when testing non-libc++.
* Add missing include: `c.math/abs.pass.cpp` uses `std::numeric_limits` but failed to `#include <limits>`.
* Don't test non-type: A "recent" change to `meta.trans.other/underlying_type.pass.cpp` unconditionally tests the type `F` which is conditionally defined.
* Use `hash<long long>` instead of `hash<short>` with `int` in `unordered_meow` deduction guide tests to avoid truncation warnings.
* Convert `3.14` explicitly in `midpoint.float.pass` since MSVC incorrectly diagnoses `float meow = 3.14;` as truncating.

Differential Revision: https://reviews.llvm.org/D68681

llvm-svn: 374248

Stack unwinding was sometimes failing when trying to unwind stacks in 32 bit ARM. I discovered this was because the EH frame register numbers were not set. This patch fixes this issue and adds a unit test to verify this doesn't regress.

Differential Revision: https://reviews.llvm.org/D68088

llvm-svn: 374246

Split the ConstantFold part into a separate file and
make it use the fixture GISelMITest.

llvm-svn: 374245

llvm-svn: 374244

Check for `nullptr` before inspecting composite function.

llvm-svn: 374243

Summary: The PlaceholderObjectFile has an assert in SetLoadAddress that fires if "m_base == value" is not true. To avoid this, we create check that the base address matches, and if it doesn't we clear the module that was found using the UUID so that we create a new PlaceholderObjectFile. Added a test to cover this issue.

Reviewers: labath, aadsm, dvlahovski

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D68106

llvm-svn: 374242

If original instruction did not have source modifiers they were
not added to the new DPP instruction as well, even if needed.

Differential Revision: https://reviews.llvm.org/D68729

llvm-svn: 374241

Also update Clang to call Builder.CreateFNeg(...) for UnaryMinus.

Differential Revision: https://reviews.llvm.org/D61675

llvm-svn: 374240

Summary:
There a a few call sites that use FILE* which are easy to
fix without disrupting anything else.

Reviewers: JDevlieghere, jasonmolenda, labath

Reviewed By: JDevlieghere, labath

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D68444

llvm-svn: 374239

Summary:
This patch add SBFile interfaces to SBCommandReturnObject, and
removes the internal callers of its FILE* interfaces.

Reviewers: JDevlieghere, jasonmolenda, labath

Reviewed By: JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D68434

llvm-svn: 374238

Summary:
It's really annoying and confusing to have to keep referring
back to earlier versions of this SBFile work to find the
tests that need to be added for each patch, and not duplicate
them with new tests.

This patch just imports all my tests.   A bunch of them don't
work yet, so they are marked to be skipped.   They'll be
unmarked as I fix them.

One of these tests will actually trip an assert in the SWIG
code now instead of just failing, so I'm fixing that here too.

Reviewers: JDevlieghere, jasonmolenda, labath

Reviewed By: JDevlieghere, labath

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D68433

llvm-svn: 374237

Add convenience methods to the Reproducer class for when you don't need
access to the generator and the loader.

llvm-svn: 374236

Summary:
This is necessary and sufficient to get simple cases of multiple
return working with multivalue enabled. More complex cases will
require block and loop signatures to be generalized to potentially be
type indices as well.

Reviewers: aheejin, dschuff

Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D68684

llvm-svn: 374235

The synchronization token handling was not remote-friendly.

llvm-svn: 374234

in ExtBinary format

Currently for Text, Binary and ExtBinary format profiles, when we compile a
module with samplefdo, even if there is no function showing up in the profile,
we have to load all the function profiles from the profile input. That is a
waste of compile time.

CompactBinary format profile has already had the support of loading function
profiles on demand. In this patch, we add the support to load profile on
demand for ExtBinary format. It will work no matter the sections in ExtBinary
format profile are compressed or not. Experiment shows it reduces the time to
compile a server benchmark by 30%.

When profile remapping and loading function profiles on demand are both used,
extra work needs to be done so that the loading on demand process will take
the name remapping into consideration. It will be addressed in a follow-up
patch.

Differential Revision: https://reviews.llvm.org/D68601

llvm-svn: 374233

Also fixing the incorrect "offset" field being computed/printed for each
location list.

llvm-svn: 374232