llvm-svn: 341043

Follow-up to D51210.

llvm-svn: 341042

Summary:
The check_clang_tidy.py script would allow mixing of `CHECK-NOTES` and `CHECK-MESSAGES` but running `FileCheck` for that would implicitly fail, because `CHECK-NOTES` bails out if there is a warning.

That means a clang-tidy test can not mix these constructs to check warnings with `CHECK-MESSAGES` and notes with `CHECK-NOTES`. The script gives now a clear error if that happens.

Reviewers: alexfh, aaron.ballman, lebedev.ri, hokein

Reviewed By: lebedev.ri

Subscribers: xazax.hun, cfe-commits

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

llvm-svn: 341039

Object linking isn't supported, so it's not useful
to emit default visibility. Default visibility requires
relocations we don't yet support for functions compiled
in another translation unit.

WebAssembly already does this, although they insert these
arguments in a different place for some reason.

llvm-svn: 341033

Follow up to D51210.

llvm-svn: 341032

This reverts commit r340997.

This change turned out not to be NFC after all, but e.g. causes
clang to crash when building the linux kernel for aarch64.

llvm-svn: 341031

Followup to D51210.

llvm-svn: 341030

Summary:
This is the first step in the larger refactoring and reduction of
D50441.

This step in the process does the following:

- Introduces more granular types of `Record`s representing the many
  kinds of records written/read by the Flight Data Recorder (FDR) mode
  `Trace` loading function(s).

- Introduces an abstract `RecordVisitor` type meant to handle the
  processing of the various `Record` derived types. This `RecordVisitor`
  has two implementations in this patch: `RecordInitializer` and
  `FDRTraceWriter`.

- We also introduce a convenience interface for building a collection of
  `Record` instances called a `LogBuilder`. This allows us to generate
  sequences of `Record` instances manually (used in unit tests but
  useful otherwise).

- The`FDRTraceWriter` class implements the `RecordVisitor` interface and
  handles the writing of metadata records to a `raw_ostream`. We
  demonstrate that in the unit test, we can generate in-memory FDR mode
  traces using the specific `Record` derived types, which we load
  through the `loadTrace(...)` function yielding valid `Trace` objects.

This patch introduces the required types and concepts for us to start
replacing the logic implemented in the `loadFDRLog` function to use the
more granular types. In subsequent patches, we will introduce more
visitor implementations which isolate the verification, printing,
indexing, production/consumption, and finally the conversion of the FDR
mode logs.

The overarching goal of these changes is to make handling FDR mode logs
better tested, more understandable, more extensible, and more
systematic. This will also allow us to better represent the execution
trace, as we improve the fidelity of the events we represent in an XRay
`Trace` object, which we intend to do after FDR mode log processing is
in better shape.

Reviewers: eizan

Reviewed By: eizan

Subscribers: mgorny, hiraditya, llvm-commits

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

llvm-svn: 341029

In computeRegisterLiveness, the max instructions to search
was counting dbg_value instructions, which could potentially
cause an observable codegen change from the presence of debug
info.

llvm-svn: 341028

If there is an unused def, this would previously
report that the register was live. Check for uses
first so that it is reported as dead if never used.

llvm-svn: 341027

If the end of the block is reached during the scan, check
the live ins of the successors. This was already done in the
other direction if the block entry was reached.

llvm-svn: 341026

Check that Machine CSE correctly handles during the transformation, the
debug location information for local variables.

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

llvm-svn: 341025

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

llvm-svn: 341024

These tests contain the pattern (neg (max ~X, C)) which we should transform to ((min X, ~C) + 1)

llvm-svn: 341023

We now only add +64bit to the CPU string for "generic" CPU. All other CPU names are assumed to have the feature flag already set if they support 64-bit. I've remove the implies from CMPXCHG8 so that Feature64Bit only comes in via CPUs or user passing -mattr=+64bit.

I've changed the assert to a report_fatal_error so it's not lost in Release builds.

The test updates are to fix things that tripped the new error.

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

llvm-svn: 341022

llvm-svn: 341021

llvm-svn: 341020

using sysctl to get the tic frequency data.
still linkage issue for X-ray_init not resolved.

Reviewers: dberris, kubamracek

Reviewed By: dberris

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

llvm-svn: 341019

If an ABI-like value is used in a different block,
the type split used is not necessarily the same as
the call's ABI. The value is used through an intermediate
copy virtual registers from the other block. This
resulted in copies with inconsistent sizes later.

Fixes regressions since r338197 when AMDGPU started
splitting vector types for calls.

llvm-svn: 341018

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

llvm-svn: 341017

Since the order and placement of the non-wanted elements might not
be obvious, it feels more straightforward to hardcode the whole list
with -NEXT elements (and checking for the end of the output with
CHECK-EMPTY) instead of adding CHECK-NOT lines at the right places
where the unwanted elements would appear if they erroneously
were to included.

llvm-svn: 341016

These classes don't make any changes to IR and have no reason to be in
Transform/Utils. This patch moves them to Analysis folder. This will allow
us reusing these classes in some analyzes, like MustExecute.

llvm-svn: 341015

rL340921 has been reverted by rL340923 due to linkage dependency
from Transform/Utils to Analysis which is not allowed. In this patch
this has been fixed, a new utility function moved to Analysis.

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

llvm-svn: 341014

ASTContext::applyObjCProtocolQualifiers will return a canonical type when given
a canonical type and an array of canonical protocols.  If the protocols are not
canonical then the returned type is also not canonical.  Since a canonical type is needed, canonicalize the returned type before using it.  This later prevents
a type from having a non-canonical canonical type.

llvm-svn: 341013

Summary:
This change implements the profile loading functionality in LLVM to
support XRay's profiling mode in compiler-rt.

We introduce a type named `llvm::xray::Profile` which allows building a
profile representation. We can load an XRay profile from a file to build
Profile instances, or do it manually through the Profile type's API.

The intent is to get the `llvm-xray` tool to generate `Profile`
instances and use that as the common abstraction through which all
conversion and analysis can be done. In the future we can generate
`Profile` instances from `Trace` instances as well, through conversion
functions.

Some of the key operations supported by the `Profile` API are:

- Path interning (`Profile::internPath(...)`) which returns a unique path
  identifier.

- Block appending (`Profile::addBlock(...)`) to add thread-associated
  profile information.

- Path ID to Path lookup (`Profile::expandPath(...)`) to look up a
  PathID and return the original interned path.

- Block iteration.

A 'Path' in this context represents the function call stack in
leaf-to-root order. This is represented as a path in an internally
managed prefix tree in the `Profile` instance. Having a handle (PathID)
to identify the unique Paths we encounter for a particular Profile
allows us to reduce the amount of memory required to associate profile
data to a particular Path.

This is the first of a series of patches to migrate the `llvm-stacks`
tool towards using a single profile representation.

Depends on D48653.

Reviewers: kpw, eizan

Reviewed By: kpw

Subscribers: kpw, thakis, mgorny, llvm-commits, hiraditya

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

llvm-svn: 341012

Now that all _zx_vmar_... calls have been updated, we can undo the
change made in r337801 and switch over to the new calls.

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

llvm-svn: 341011

We don't have enough information to know if struct types being
bitcast will cause validation failures or not, so be conservative
and allow such cases to persist (fot now).

Fixes: https://bugs.llvm.org/show_bug.cgi?id=38711

Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits

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

llvm-svn: 341010

how we parse source code.

Instead of implicitly opting all undocumented attributes out of '#pragma
clang attribute' support, explicitly opt them all out and remove the
documentation check from TableGen.

(No new attributes should be added without documentation, so this has
little chance of backsliding. We already support the pragma on one
undocumented attribute, so we don't even want to enforce our old
"rule".)

No functionality change intended.

llvm-svn: 341009

Summary:
Global variables that are external and zero initialized are
supposed to be merged with global variables in the bss section
rather than the data section.

Reviewers: efriedma, rengolin, t.p.northover, javed.absar, asl, john.brawn, pcc

Reviewed By: efriedma

Subscribers: dmgreen, llvm-commits

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

llvm-svn: 341008

[hwasan] add a simple threaded UAF test, make it work on x86 (need to disable tagging in malloc with inside pthread_create)

llvm-svn: 341007

... and remove the dummy implementations from the languages that do not
support it.

llvm-svn: 341006

llvm-svn: 341005

llvm-svn: 341004

Summary:
The syntax highlighting feature so far is mutually exclusive with the lldb feature
that marks the current column in the line by underlining it via an ANSI color code.
Meaning that if you enable one, the other is automatically disabled by LLDB.

This was caused by the fact that both features inserted color codes into the the
source code and were likely to interfere with each other (which would result
in a broken source code printout to the user).

This patch moves the cursor code into the highlighting framework, which provides
the same feature to the user in normal non-C source code. For any source code
that is highlighted by Clang, we now also have cursor marking for the whole token
that is under the current source location. E.g., before we underlined only the '!' in the
expression '1 != 2', but now the whole token '!=' is underlined. The same for function
calls and so on. Below you can see two examples where we before only underlined
the first character of the token, but now underline the whole token.

{F7075400}
{F7075414}

It also simplifies the DisplaySourceLines method in the SourceManager as most of
the code in there was essentially just for getting this column marker to work as
a FormatEntity.

Reviewers: aprantl

Reviewed By: aprantl

Subscribers: lldb-commits

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

llvm-svn: 341003

llvm-svn: 341002

The cost modeling was not accounting for the fact we were duplicating the instruction once per predecessor.  With a default threshold of 1, this meant we were actually creating #pred copies.

Adding to the fun, there is *absolutely no* test coverage for this.  Simply bailing for more than one predecessor passes all checked in tests.

llvm-svn: 341001

These bugs were found by writing a Python script which spidered
the entire Chromium build directory tree demangling every symbol
in every object file.  At the start, the tool printed:

  Processed 27443 object files.
  2926377/2936108 symbols successfully demangled (99.6686%)
  9731 symbols could not be demangled (0.3314%)
  14589 files crashed while demangling (53.1611%)

After this patch, it prints:

  Processed 27443 object files.
  41295518/41295617 symbols successfully demangled (99.9998%)
  99 symbols could not be demangled (0.0002%)
  0 files crashed while demangling (0.0000%)

The issues fixed in this patch are:

  * Ignore empty parameter packs.  Previously we would encounter
    a mangling for an empty parameter pack and add a null node
    to the AST.  Since we don't print these anyway, we now just
    don't add anything to the AST and ignore it entirely.  This
    fixes some of the crashes.

  * Account for "incorrect" string literal demanglings.  Apparently
    an older version of clang would not truncate mangled string
    literals to 32 bytes of encoded character data.  The demangling
    code however would allocate a 32 byte buffer thinking that it
    would not encounter more than this, and overrun the buffer.
    We now demangle up to 128 bytes of data, since the buggy
    clang would encode up to 32 *characters* of data.

  * Extended support for demangling init-fini stubs.  If you had
    something like
      struct Foo {
        static vector<string> S;
      };
    this would generate a dynamic atexit initializer *for the
    variable*.  We didn't handle this, but now we print something
    nice.  This is actually an improvement over undname, which will
    fail to demangle this at all.

  * Fixed one case of static this adjustment.  We weren't handling
    several thunk codes so we didn't recognize the mangling.  These
    are now handled.

  * Fixed a back-referencing problem.  Member pointer templates
    should have their components considered for back-referencing

The remaining 99 symbols which can't be demangled are all symbols
which are compiler-generated and undname can't demangle either.

llvm-svn: 341000

This should more accurately reflect what the AsmPrinter will actually
do.

This is NFC, as far as I can tell; all the places that might be affected
already have an extra check to avoid using the result of
getPreferredAlignment in this situation.

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

llvm-svn: 340999

These symbols are declared early with the same value, so they otherwise
appear identical to ICF.

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

llvm-svn: 340998

llvm-svn: 340997