AsmWriter/Bitcode: MDSubrange

llvm-svn: 229003

Misc documentation/comment fixes.

llvm-svn: 228093

IR: Assembly and bitcode for GenericDebugNode

llvm-svn: 228041

IR: Split out DebugInfoMetadata.h, NFC

Move debug-info-centred `Metadata` subclasses into their own
header/source file. A couple of private template functions are needed
from both `Metadata.cpp` an

IR: Split out DebugInfoMetadata.h, NFC

Move debug-info-centred `Metadata` subclasses into their own
header/source file. A couple of private template functions are needed
from both `Metadata.cpp` and `DebugInfoMetadata.cpp`, so I've moved them
to `lib/IR/MetadataImpl.h`.

llvm-svn: 227835

show more ...

Check bit widths before trying to get a type.

Added a test case for it.
Also added run lines for the test case in r227566.

Bugs found with afl-fuzz

llvm-svn: 227589

[bitcode reader] Fix an assert on invalid type tables

Bug found with afl-fuzz

llvm-svn: 227566

Bitcode: Don't create comdats when autoupgrading macho bitcode

Don't infer COMDAT groups from older bitcode if the target is macho,
it doesn't have COMDATs.

llvm-svn: 226546

IR: Merge UniquableMDNode back into MDNode, NFC

As pointed out in r226501, the distinction between `MDNode` and
`UniquableMDNode` is confusing. When we need subclasses of `MDNode`
that don't use al

IR: Merge UniquableMDNode back into MDNode, NFC

As pointed out in r226501, the distinction between `MDNode` and
`UniquableMDNode` is confusing. When we need subclasses of `MDNode`
that don't use all its functionality it might make sense to break it
apart again, but until then this makes the code clearer.

llvm-svn: 226520

show more ...

IR: Return unique_ptr from MDNode::getTemporary()

Change `MDTuple::getTemporary()` and `MDLocation::getTemporary()` to
return (effectively) `std::unique_ptr<T, MDNode::deleteTemporary>`, and
clean u

IR: Return unique_ptr from MDNode::getTemporary()

Change `MDTuple::getTemporary()` and `MDLocation::getTemporary()` to
return (effectively) `std::unique_ptr<T, MDNode::deleteTemporary>`, and
clean up call sites. (For now, `DIBuilder` call sites just call
`release()` immediately.)

There's an accompanying change in each of clang and polly to use the new
API.

llvm-svn: 226504

show more ...

IR: Remove MDNodeFwdDecl

Remove `MDNodeFwdDecl` (as promised in r226481). Aside from API
changes, there's no real functionality change here.
`MDNode::getTemporary()` now forwards to `MDTuple::getTe

IR: Remove MDNodeFwdDecl

Remove `MDNodeFwdDecl` (as promised in r226481). Aside from API
changes, there's no real functionality change here.
`MDNode::getTemporary()` now forwards to `MDTuple::getTemporary()`,
which returns a tuple with `isTemporary()` equal to true.

The main point is that we can now add temporaries of other `MDNode`
subclasses, needed for PR22235 (I introduced `MDNodeFwdDecl` in the
first place because I didn't recognize this need, and thought they were
only needed to handle forward references).

A few things left out of (or highlighted by) this commit:

- I've had to remove the (few) uses of `std::unique_ptr<>` to deal
with temporaries, since the destructor is no longer public.
`getTemporary()` should probably return the equivalent of
`std::unique_ptr<T, MDNode::deleteTemporary>`.
- `MDLocation::getTemporary()` doesn't exist yet (worse, it actually
does exist, but does the wrong thing: `MDNode::getTemporary()` is
inherited and returns an `MDTuple`).
- `MDNode` now only has one subclass, `UniquableMDNode`, and the
distinction between them is actually somewhat confusing.

I'll fix those up next.

llvm-svn: 226501

show more ...

Bring r226038 back.

No change in this commit, but clang was changed to also produce trivial comdats when
needed.

Original message:

Don't create new comdats in CodeGen.

This patch stops the implic

Bring r226038 back.

No change in this commit, but clang was changed to also produce trivial comdats when
needed.

Original message:

Don't create new comdats in CodeGen.

This patch stops the implicit creation of comdats during codegen.

Clang now sets the comdat explicitly when it is required. With this patch clang and gcc
now produce the same result in pr19848.

llvm-svn: 226467

show more ...

Revert r226242 - Revert Revert Don't create new comdats in CodeGen

This breaks AddressSanitizer (ninja check-asan) on Windows

llvm-svn: 226251

Revert "Revert Don't create new comdats in CodeGen"

This reverts commit r226173, adding r226038 back.

No change in this commit, but clang was changed to also produce trivial comdats for
costructors

Revert "Revert Don't create new comdats in CodeGen"

This reverts commit r226173, adding r226038 back.

No change in this commit, but clang was changed to also produce trivial comdats for
costructors, destructors and vtables when needed.

Original message:

Don't create new comdats in CodeGen.

This patch stops the implicit creation of comdats during codegen.

Clang now sets the comdat explicitly when it is required. With this patch clang and gcc
now produce the same result in pr19848.

llvm-svn: 226242

show more ...

Revert Don't create new comdats in CodeGen

It breaks AddressSanitizer on Windows.

llvm-svn: 226173

Don't create new comdats in CodeGen.

This patch stops the implicit creation of comdats during codegen.

Clang now sets the comdat explicitly when it is required. With this patch clang and gcc
now pr

Don't create new comdats in CodeGen.

This patch stops the implicit creation of comdats during codegen.

Clang now sets the comdat explicitly when it is required. With this patch clang and gcc
now produce the same result in pr19848.

llvm-svn: 226038

show more ...

[cleanup] Re-sort all the #include lines in LLVM using
utils/sort_includes.py.

I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the Inst

[cleanup] Re-sort all the #include lines in LLVM using
utils/sort_includes.py.

I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.

llvm-svn: 225974

show more ...

AsmParser/Bitcode: Add support for MDLocation

This adds assembly and bitcode support for `MDLocation`. The assembly
side is rather big, since this is the first `MDNode` subclass (that
isn't `MDTupl

AsmParser/Bitcode: Add support for MDLocation

This adds assembly and bitcode support for `MDLocation`. The assembly
side is rather big, since this is the first `MDNode` subclass (that
isn't `MDTuple`). Part of PR21433.

(If you're wondering where the mountains of testcase updates are, we
don't need them until I update `DILocation` and `DebugLoc` to actually
use this class.)

llvm-svn: 225830

show more ...

IR: Split GenericMDNode into MDTuple and UniquableMDNode

Split `GenericMDNode` into two classes (with more descriptive names).

- `UniquableMDNode` will be a common subclass for `MDNode`s that are

IR: Split GenericMDNode into MDTuple and UniquableMDNode

Split `GenericMDNode` into two classes (with more descriptive names).

- `UniquableMDNode` will be a common subclass for `MDNode`s that are
sometimes uniqued like constants, and sometimes 'distinct'.

This class gets the (short-lived) RAUW support and related API.

- `MDTuple` is the basic tuple that has always been returned by
`MDNode::get()`. This is as opposed to more specific nodes to be
added soon, which have additional fields, custom assembly syntax,
and extra semantics.

This class gets the hash-related logic, since other sublcasses of
`UniquableMDNode` may need to hash based on other fields.

To keep this diff from getting too big, I've added casts to `MDTuple`
that won't really scale as new subclasses of `UniquableMDNode` are
added, but I'll clean those up incrementally.

(No functionality change intended.)

llvm-svn: 225682

show more ...

Use the DiagnosticHandler to print diagnostics when reading bitcode.

The bitcode reading interface used std::error_code to report an error to the
callers and it is the callers job to print diagnosti

Use the DiagnosticHandler to print diagnostics when reading bitcode.

The bitcode reading interface used std::error_code to report an error to the
callers and it is the callers job to print diagnostics.

This is not ideal for error handling or diagnostic reporting:

* For error handling, all that the callers care about is 3 possibilities:
* It worked
* The bitcode file is corrupted/invalid.
* The file is not bitcode at all.

* For diagnostic, it is user friendly to include far more information
about the invalid case so the user can find out what is wrong with the
bitcode file. This comes up, for example, when a developer introduces a
bug while extending the format.

The compromise we had was to have a lot of error codes.

With this patch we use the DiagnosticHandler to communicate with the
human and std::error_code to communicate with the caller.

This allows us to have far fewer error codes and adds the infrastructure to
print better diagnostics. This is so because the diagnostics are printed when
he issue is found. The code that detected the problem in alive in the stack and
can pass down as much context as needed. As an example the patch updates
test/Bitcode/invalid.ll.

Using a DiagnosticHandler also moves the fatal/non-fatal error decision to the
caller. A simple one like llvm-dis can just use fatal errors. The gold plugin
needs a bit more complex treatment because of being passed non-bitcode files. An
hypothetical interactive tool would make all bitcode errors non-fatal.

llvm-svn: 225562

show more ...

Revert "Bitcode: Move the DEBUG_LOC record to DEBUG_LOC_OLD"

This reverts commit r225498 (but leaves r225499, which was a worthy
cleanup).

My plan was to change `DEBUG_LOC` to store the `MDNode` di

Revert "Bitcode: Move the DEBUG_LOC record to DEBUG_LOC_OLD"

This reverts commit r225498 (but leaves r225499, which was a worthy
cleanup).

My plan was to change `DEBUG_LOC` to store the `MDNode` directly rather
than its operands (patch was to go out this morning), but on reflection
it's not clear that it's strictly better. (I had missed that the
current code is unlikely to emit the `MDNode` at all.)

Conflicts:
lib/Bitcode/Reader/BitcodeReader.cpp (due to r225499)

llvm-svn: 225531

show more ...

Bitcode: Share logic for last instruction, NFC

Share logic for getting the last instruction emitted.

llvm-svn: 225499

Bitcode: Move the DEBUG_LOC record to DEBUG_LOC_OLD

Prepare to simplify the `DebugLoc` record.

llvm-svn: 225498

IR: Add 'distinct' MDNodes to bitcode and assembly

Propagate whether `MDNode`s are 'distinct' through the other types of IR
(assembly and bitcode). This adds the `distinct` keyword to assembly.

Cu

IR: Add 'distinct' MDNodes to bitcode and assembly

Propagate whether `MDNode`s are 'distinct' through the other types of IR
(assembly and bitcode). This adds the `distinct` keyword to assembly.

Currently, no one actually calls `MDNode::getDistinct()`, so these nodes
only get created for:

- self-references, which are never uniqued, and
- nodes whose operands are replaced that hit a uniquing collision.

The concept of distinct nodes is still not quite first-class, since
distinct-ness doesn't yet survive across `MapMetadata()`.

Part of PR22111.

llvm-svn: 225474

show more ...

Explicitly handle LinkOnceODRAutoHideLinkage. NFC. We already have a test.

llvm-svn: 225449

Update naming style and clang-format. NFC.

llvm-svn: 225448