[CodeGen] Qualify auto variables in for loops (NFC)

[MC] De-capitalize SwitchSection. NFC

Add SwitchSection to return switchSection. The API will be removed soon.

[FaultsMaps][llvm-objdump] Move FaultMapParser to Object/. Remove CodeGen dependency from llvm-objdump

FaultsMapParser lived in CodeGen and was forcing llvm-objdump to
link CodeGen and everything Co

[FaultsMaps][llvm-objdump] Move FaultMapParser to Object/. Remove CodeGen dependency from llvm-objdump

FaultsMapParser lived in CodeGen and was forcing llvm-objdump to
link CodeGen and everything CodeGen depends on.

This was previously attempted in r240364 to fix a link failure.
The CodeGen dependency was independently added to fix the same
link failure, and that ended up being kept.

Removing the dependency seems like the correct layering for
llvm-objdump.

Reviewed By: MaskRay, jhenderson

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

show more ...

[MC] Add MCStreamer::emitInt{8,16,32,64}

Similar to AsmPrinter::emitInt{8,16,32,64}.

[MCStreamer] De-capitalize EmitValue EmitIntValue{,InHex}

[MC] De-capitalize another set of MCStreamer::Emit* functions

Emit{ValueTo,Code}Alignment Emit{DTP,TP,GP}* EmitSymbolValue etc

[FaultMaps] Make label formation a bit more explicit [NFC]

This is in advance of assembler padding directives support where we'll need to bundle the label w/the corresponding faulting instruction to

[FaultMaps] Make label formation a bit more explicit [NFC]

This is in advance of assembler padding directives support where we'll need to bundle the label w/the corresponding faulting instruction to avoid padding being inserted between.

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Rename DEBUG macro to LLVM_DEBUG.

The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/

Rename DEBUG macro to LLVM_DEBUG.

The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM
- Manual change to APInt
- Manually chage DOCS as regex doesn't match it.

In the transition period the DEBUG() macro is still present and aliased
to the LLVM_DEBUG() one.

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

llvm-svn: 332240

show more ...

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.

I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.

This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.

Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).

llvm-svn: 304787

show more ...

[CodeGen] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 296404

[ImplicitNullCheck] Extend Implicit Null Check scope by using stores

Summary:
This change allows usage of store instruction for implicit null check.

Memory Aliasing Analisys is not used and change

[ImplicitNullCheck] Extend Implicit Null Check scope by using stores

Summary:
This change allows usage of store instruction for implicit null check.

Memory Aliasing Analisys is not used and change conservatively supposes
that any store and load may access the same memory. As a result
re-ordering of store-store, store-load and load-store is prohibited.

Patch by Serguei Katkov!

Reviewers: reames, sanjoy

Reviewed By: sanjoy

Subscribers: atrick, llvm-commits

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

llvm-svn: 294338

show more ...

Revert "[FaultMaps] Move FaultMapParser to Object/"

This reverts commit r240364 (git c49542e5bb186). The issue r240364 was
trying to fix was fixed independently in r240362.

llvm-svn: 240448

[FaultMaps] Move FaultMapParser to Object/

Summary:
That way llvm-objdump can rely on it without adding an extra dependency
on CodeGen.

This change duplicates the FaultKind enum and the code that s

[FaultMaps] Move FaultMapParser to Object/

Summary:
That way llvm-objdump can rely on it without adding an extra dependency
on CodeGen.

This change duplicates the FaultKind enum and the code that serializes
it to a string. I could not figure out a way to get around this without
adding a new dependency to Object

Reviewers: rafael, ab

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D10619

llvm-svn: 240364

show more ...

Fix MSVC build.

I had some unnecessary `typename`s left in after addressing review.
This compiled successfully with clang++ but MSVC reported an error. Fix
the build error by removing the redundant

Fix MSVC build.

I had some unnecessary `typename`s left in after addressing review.
This compiled successfully with clang++ but MSVC reported an error. Fix
the build error by removing the redundant `typename`s.

llvm-svn: 240307

show more ...

[FaultMaps] Add a parser for the __llvm__faultmaps section.

Summary:
The parser is exercised by llvm-objdump using -print-fault-maps. As is
probably obvious, the code itself was "heavily inspired"

[FaultMaps] Add a parser for the __llvm__faultmaps section.

Summary:
The parser is exercised by llvm-objdump using -print-fault-maps. As is
probably obvious, the code itself was "heavily inspired" by
http://reviews.llvm.org/D10434.

Reviewers: reames, atrick, JosephTremoulet

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D10491

llvm-svn: 240304

show more ...

Unbreak the build from r239740.

Do not re-use an enum name as a field name. Some bots don't like this.

llvm-svn: 239746

[CodeGen] Introduce a FAULTING_LOAD_OP pseudo-op.

Summary:
This instruction encodes a loading operation that may fault, and a label
to branch to if the load page-faults. The locations of potentiall

[CodeGen] Introduce a FAULTING_LOAD_OP pseudo-op.

Summary:
This instruction encodes a loading operation that may fault, and a label
to branch to if the load page-faults. The locations of potentially
faulting loads and their "handler" destinations are recorded in a
FaultMap section, meant to be consumed by LLVM's clients.

Nothing generates FAULTING_LOAD_OP instructions yet, but they will be
used in a future change.

The documentation (FaultMaps.rst) needs improvement and I will update
this diff with a more expanded version shortly.

Depends on D10196

Reviewers: rnk, reames, AndyAyers, ab, atrick, pgavlin

Reviewed By: atrick, pgavlin

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D10197

llvm-svn: 239740

show more ...