Formatting with clang-format patch r280700

llvm-svn: 280716

DebugInfo: use strongly typed enum for debug info flags

Use ADT/BitmaskEnum for DINode::DIFlags for the following purposes:

Get rid of unsigned int for flags to avoid problems on platforms with siz

DebugInfo: use strongly typed enum for debug info flags

Use ADT/BitmaskEnum for DINode::DIFlags for the following purposes:

Get rid of unsigned int for flags to avoid problems on platforms with sizeof(int) < 4
Flags are now strongly typed
Patch by: Victor Leschuk <vleschuk@gmail.com>

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

llvm-svn: 280700

show more ...

Revert "DebugInfo: use strongly typed enum for debug info flags"

This reverts commit r280686, bots are broken.

llvm-svn: 280688

DebugInfo: use strongly typed enum for debug info flags

Use ADT/BitmaskEnum for DINode::DIFlags for the following purposes:
* Get rid of unsigned int for flags to avoid problems on platforms wit

DebugInfo: use strongly typed enum for debug info flags

Use ADT/BitmaskEnum for DINode::DIFlags for the following purposes:
* Get rid of unsigned int for flags to avoid problems on platforms with sizeof(int) < 4
* Flags are now strongly typed

Patch by: Victor Leschuk <vleschuk@gmail.com>

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

llvm-svn: 280686

show more ...

Fix some Clang-tidy modernize-use-using and Include What You Use warnings; other minor fixes.

Differential revision: https://reviews.llvm.org/D23861

llvm-svn: 279695

DebugInfo: Add flag to CU to disable emission of inline debug info into the skeleton CU

In cases where .dwo/.dwp files are guaranteed to be available, skipping
the extra online (in the .o file) inli

DebugInfo: Add flag to CU to disable emission of inline debug info into the skeleton CU

In cases where .dwo/.dwp files are guaranteed to be available, skipping
the extra online (in the .o file) inline info can save a substantial
amount of space - see the original r221306 for more details there.

llvm-svn: 279650

show more ...

Replace "fallthrough" comments with LLVM_FALLTHROUGH

This is a mechanical change of comments in switches like fallthrough,
fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead.

llvm

Replace "fallthrough" comments with LLVM_FALLTHROUGH

This is a mechanical change of comments in switches like fallthrough,
fall-through, or fall-thru to use the LLVM_FALLTHROUGH macro instead.

llvm-svn: 278902

show more ...

Fix bitcode auto-upgrade when using bitcode lazy loading

The auto-upgrade path could be called before the VST (global
names) was fully parsed, and thus intrinsic names were not
available and the aut

Fix bitcode auto-upgrade when using bitcode lazy loading

The auto-upgrade path could be called before the VST (global
names) was fully parsed, and thus intrinsic names were not
available and the autoupgrade logic could not operate.

Fix link failures with ThinLTO.

This is a recommit of r278610 with a different fix.

llvm-svn: 278615

show more ...

Revert "Fix bitcode auto-upgrade when using bitcode lazy loading"

This reverts commit r278610. Tests are broken

llvm-svn: 278613

Fix bitcode auto-upgrade when using bitcode lazy loading

The auto-upgrade path could be called before the VST (global
names) was fully parsed, and thus intrinsic names were not
available and the aut

Fix bitcode auto-upgrade when using bitcode lazy loading

The auto-upgrade path could be called before the VST (global
names) was fully parsed, and thus intrinsic names were not
available and the autoupgrade logic could not operate.

Fix link failures with ThinLTO.

llvm-svn: 278610

show more ...

Use the range variant of transform instead of unpacking begin/end

No functionality change is intended.

llvm-svn: 278476

Don't import variadic functions

Summary:
This patch adds IsVariadicFunction bit to summary in order
to not import variadic functions. Inliner doesn't inline
variadic functions because it is hard to

Don't import variadic functions

Summary:
This patch adds IsVariadicFunction bit to summary in order
to not import variadic functions. Inliner doesn't inline
variadic functions because it is hard to reason about it.

This one small fix improves Importer by about 16%
(going from 86% to 100% of imported functions that are
inlined anywhere)
on some spec benchmarks like 'int' and others.

Reviewers: eraman, mehdi_amini, tejohnson

Subscribers: mehdi_amini, llvm-commits

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

llvm-svn: 278432

show more ...

Add a libLTO API to query a memory buffer and check if it contains ObjC categories

The linker supports a feature to force load an object from a static
archive if it defines an Objective-C category.

Add a libLTO API to query a memory buffer and check if it contains ObjC categories

The linker supports a feature to force load an object from a static
archive if it defines an Objective-C category.
This API supports this feature by looking at every section in the
module to find if a category is defined in the module.

llvm-svn: 275125

show more ...

Add writeonly IR attribute

Summary:
This complements the earlier addition of IntrWriteMem and IntrWriteArgMem
LLVM intrinsic properties, see D18291.

Also start using the attribute for memset, memcp

Add writeonly IR attribute

Summary:
This complements the earlier addition of IntrWriteMem and IntrWriteArgMem
LLVM intrinsic properties, see D18291.

Also start using the attribute for memset, memcpy, and memmove intrinsics,
and remove their special-casing in BasicAliasAnalysis.

Reviewers: reames, joker.eph

Subscribers: joker.eph, llvm-commits

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

llvm-svn: 274485

show more ...

[codeview] Add DISubprogram::ThisAdjustment

Summary:
This represents the adjustment applied to the implicit 'this' parameter
in the prologue of a virtual method in the MS C++ ABI. The adjustment is

[codeview] Add DISubprogram::ThisAdjustment

Summary:
This represents the adjustment applied to the implicit 'this' parameter
in the prologue of a virtual method in the MS C++ ABI. The adjustment is
always zero unless multiple inheritance is involved.

This increases the size of DISubprogram by 8 bytes, unfortunately. The
adjustment really is a signed 32-bit integer. If this size increase is
too much, we could probably win it back by splitting out a subclass with
info specific to virtual methods (virtuality, vindex, thisadjustment,
containingType).

Reviewers: aprantl, dexonsmith

Subscribers: aaboud, amccarth, llvm-commits

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

llvm-svn: 274325

show more ...

Remangle intrinsics names when types are renamed

This is a resubmittion of previously reverted rL273568.

This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail threa

Remangle intrinsics names when types are renamed

This is a resubmittion of previously reverted rL273568.

This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html

Reviewers: mehdi_amini, reames

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

llvm-svn: 273686

show more ...

Revert r273568 "Remangle intrinsics names when types are renamed"

It broke 2008-07-15-Bswap.ll and 2009-09-01-PostRAProlog.ll

llvm-svn: 273574

Remangle intrinsics names when types are renamed

This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-April/09

Remangle intrinsics names when types are renamed

This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html

Reviewers: mehdi_amini, reames

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

llvm-svn: 273568

show more ...

Delete more dead code.

Found by gcc 6.

llvm-svn: 273402

IR: Allow metadata attachments on declarations, and fix lazy loaded metadata issue with globals.

This change is motivated by an upcoming change to the metadata representation
used for CFI. The indir

IR: Allow metadata attachments on declarations, and fix lazy loaded metadata issue with globals.

This change is motivated by an upcoming change to the metadata representation
used for CFI. The indirect function call checker needs type information for
external function declarations in order to correctly generate jump table
entries for such declarations. We currently associate such type information
with declarations using a global metadata node, but I plan [1] to move all
such metadata to global object attachments.

In bitcode, metadata attachments for function declarations appear in the
global metadata block. This seems reasonable to me because I expect metadata
attachments on declarations to be uncommon. In the long term I'd also expect
this to be the case for CFI, because we'd want to use some specialized bitcode
format for this metadata that could be read as part of the ThinLTO thin-link
phase, which would mean that it would not appear in the global metadata block.

To solve the lazy loaded metadata issue I was seeing with D20147, I use the
same bitcode representation for metadata attachments for global variables as I
do for function declarations. Since there's a use case for metadata attachments
in the global metadata block, we might as well use that representation for
global variables as well, at least until we have a mechanism for lazy loading
global variables.

In the assembly format, the metadata attachments appear after the "declare"
keyword in order to avoid a parsing ambiguity.

[1] http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html

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

llvm-svn: 273336

show more ...

Apply another batch of fixes from clang-tidy's performance-unnecessary-value-param.

Contains some manual fixes. No functionality change intended.

llvm-svn: 273047

IR: Introduce local_unnamed_addr attribute.

If a local_unnamed_addr attribute is attached to a global, the address
is known to be insignificant within the module. It is distinct from the
existing un

IR: Introduce local_unnamed_addr attribute.

If a local_unnamed_addr attribute is attached to a global, the address
is known to be insignificant within the module. It is distinct from the
existing unnamed_addr attribute in that it only describes a local property
of the module rather than a global property of the symbol.

This attribute is intended to be used by the code generator and LTO to allow
the linker to decide whether the global needs to be in the symbol table. It is
possible to exclude a global from the symbol table if three things are true:
- This attribute is present on every instance of the global (which means that
the normal rule that the global must have a unique address can be broken without
being observable by the program by performing comparisons against the global's
address)
- The global has linkonce_odr linkage (which means that each linkage unit must have
its own copy of the global if it requires one, and the copy in each linkage unit
must be the same)
- It is a constant or a function (which means that the program cannot observe that
the unique-address rule has been broken by writing to the global)

Although this attribute could in principle be computed from the module
contents, LTO clients (i.e. linkers) will normally need to be able to compute
this property as part of symbol resolution, and it would be inefficient to
materialize every module just to compute it.

See:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html
for earlier discussion.

Part of the fix for PR27553.

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

llvm-svn: 272709

show more ...

BitcodeReader: Use std:::piecewise_construct when upgrading type refs

r267296 used std::piecewise_construct without using
std::forward_as_tuple, and r267298 hacked it out (using an emplace_back
foll

BitcodeReader: Use std:::piecewise_construct when upgrading type refs

r267296 used std::piecewise_construct without using
std::forward_as_tuple, and r267298 hacked it out (using an emplace_back
followed by a couple of reset() calls) because of a problem on a bot.
I'm finally circling back to call forward_as_tuple as I should have to
begin with (thanks to David Blaikie for pointing out the missing piece).

Note that this code uses emplace_back() instead of
push_back(make_pair()) because the move constructor for TrackingMDRef is
expensive (cheaper than a copy, but still expensive).

llvm-svn: 272306

show more ...

[DebugInfo] Add calling convention support for DWARF and CodeView

Summary:
Now DISubroutineType has a 'cc' field which should be a DW_CC_ enum. If
it is present and non-zero, the backend will emit

[DebugInfo] Add calling convention support for DWARF and CodeView

Summary:
Now DISubroutineType has a 'cc' field which should be a DW_CC_ enum. If
it is present and non-zero, the backend will emit it as a
DW_AT_calling_convention attribute. On the CodeView side, we translate
it to the appropriate enum for the LF_PROCEDURE record.

I added a new LLVM vendor specific enum to the list of DWARF calling
conventions. DWARF does not appear to attempt to standardize these, so I
assume it's OK to do this until we coordinate with GCC on how to emit
vectorcall convention functions.

Reviewers: dexonsmith, majnemer, aaboud, amccarth

Subscribers: mehdi_amini, llvm-commits

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

llvm-svn: 272197

show more ...

[BitCode] Make sure atomicrmw's argument is an actual PointerType

llvm-svn: 271851