"Commands" was ambiguous because in the linker script, everything is
a command. We used to handle only SECTIONS commands, and at the time,
it might make sense to call them the commands, but it is no longer
the case. We handle not only SECTIONS but also MEMORY, PHDRS, VERSION,
etc., and they are all commands.

llvm-svn: 315409

We want to check whether the using (shadow) declaration itself is visible, not
whether its target is visible.

llvm-svn: 315408

[libFuzzer] experimental flag to tweak the corpus distribution. Seems to improve the situation dramatically on the png benchmark and make things worse on a number of micro-puzzles. Needs more A/B testing 

llvm-svn: 315407

Of course, casting an unsigned value too large for 'int' is UB. So,
write out the ternary. LLVM folds it to ADD anyway.

Fixes the warning from r303693 a different way.

Thanks to Erich Keane for pointing this out!

llvm-svn: 315406

HasSections is true if there is at least one SECTIONS linker
script command, and it is not directly related to whether we have
section objects or not. So I think the new name is better.

llvm-svn: 315405

llvm-svn: 315404

ScriptConfiguration was a class to contain parsed results of
linker scripts. LinkerScript is a class to interpret it.

That ditinction was needed because we haven't instantiated
LinkerScript early (because, IIRC, LinkerScript class was a
ELFT template function). So, when we parse linker scripts,
we couldn't directly store the result to a LinkerScript instance.

Now, that limitation is gone. We instantiate LinkerScript
at the very beginning of our main function. We can directly
store parse results to a LinkerScript instance.

llvm-svn: 315403

llvm-svn: 315402

Because addRegular's functionality is tightly coupled with
addSymbol, and the former is called only once, it makes sense
to merge the two functions. This patch also adds comments.

llvm-svn: 315401

Fixes PR34306.

This is because it usually results in more compact code, and because
there are also known code generation bugs when using the PIC model
(see bug).

Based on a patch by Carlo Kok.

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

llvm-svn: 315400

[X86] Remove temporary std::string creation from shuffle comment printing. We can just write directly to the raw_ostream.

llvm-svn: 315399

Credit to OSS-Fuzz for discovery:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3137#c5

rdar://34923985

llvm-svn: 315398

llvm-svn: 315397

The tests have been enabled by accident in r315389.

llvm-svn: 315396

llvm-svn: 315395

I think three ctors are too many for this simple class.

llvm-svn: 315394

llvm-svn: 315393

This change adds a new function, CodeGen::getFieldNumber, that
enables a user of clang's code generation to get the field number
in a generated LLVM IR struct that corresponds to a particular field
in a C struct.

It is important to expose this information in Clang's code generation
interface because there is no reasonable way for users of Clang's code
generation to get this information. In particular:

LLVM struct types do not include field names.
Clang adds a non-trivial amount of logic to the code generation of LLVM IR types for structs, in particular to handle padding and bit fields.

Patch by Michael Ferguson!

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

llvm-svn: 315392

Since r315388 we have a shorter way to say this, so we'll replace
MI->getParent()->getParent() with MI->getMF() in a few places.

llvm-svn: 315390

This is a very poorly named feature. I think originally it meant to cover linux only, but the use of it in msan
seems to be about any aarch64 platform. Anyway, this change should be NFC on everything except Android.

llvm-svn: 315389

Similarly to how Instruction has getFunction, this adds a less verbose
way to write MI->getParent()->getParent(). I'll follow up shortly with
a change that changes a bunch of the uses.

llvm-svn: 315388

Previously LLDB required the DWP file 
to be located next to the executable file.
This diff uses the helper function 
Symbols::LocateExecutableSymbolFile to search for 
DWP files in the standard locations for debug symbols.

Test plan:

Build a toy test example:
main.cpp
clang -gsplit-dwarf -g -O0 main.cpp -o main.exe
llvm-dwp -e main.exe -o main.exe.dwp
mkdir -p debug_symbols
mv main.exe.dwp debug_symbols/main.exe.dwp

Run lldb:
lldb
settings set target.debug-file-search-paths ./debug_symbols
file ./main.exe
br set --name f
run

Check that debugging works:
setting breakpoints, printing local variables.

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

llvm-svn: 315387

llvm-svn: 315386

This change adds the ability to use the "-R"/"-remove-section" option
multiple times.

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

llvm-svn: 315385

The condition whether a section is alive or not by default
is becoming increasingly complex, so the decision of garbage
collection is spreading over InputSection.h and MarkLive.cpp,
which is not a good state.

This moves the code to MarkLive.cpp, to keep the file the central
place to make decisions about garbage collection.

llvm-svn: 315384

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

llvm-svn: 315383

We already have these patterns for AVX512VL, but not AVX1 or 2.

llvm-svn: 315382

[Modules TS] Diagnose attempts to enter module implementation units without the module interface being available.

llvm-svn: 315381

llvm-svn: 315380

When declaring an entity in the "purview" of a module, it's never a
redeclaration of an entity in the purview of a default module or in no module
("in the global module"). Don't consider those other declarations as possible
redeclaration targets if they're not visible, and reject any cases where we
pick a prior visible declaration that violates this rule.

This reinstates r315251 and r315256, reverted in r315309 and r315308
respectively, tweaked to avoid triggering a linkage calculation when declaring
implicit special members (this exposed our pre-existing issue with typedef
names for linkage changing the linkage of types whose linkage has already been
computed and cached in more cases). A testcase for that regression has been
added in r315366.

llvm-svn: 315379

This allows clients to avoid an unnecessary fs::status() call on each
directory entry. Because the information returned by FindFirstFileEx
is a subset of the information returned by a regular status() call,
I needed to extract a base class from file_status that contains only
that information.

On my machine, this reduces the time required to enumerate a ThinLTO
cache directory containing 520k files from almost 4 minutes to less
than 2 seconds.

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

llvm-svn: 315378

llvm-svn: 315377

With this all clients have to use the new create method which returns
an Expected.

Fixes a crash on invalid input.

llvm-svn: 315376

llvm-svn: 315375

I think it got accidentally enabled in r315105 or thereabouts.

llvm-svn: 315374

This patch changes the work lists from std::vector to SmallVector, which
matches the SCCP implementation. This patch also updates some related comments.

llvm-svn: 315373

[llvm-objcopy] Fix latent bug that allowed some Sections to be improperly cast to StringTableSections

If a Section had Type SHT_STRTAB (which could happen if you had a
.dynstr section) it was possible to cast Section to StringTableSection
and get away with any operation that was supported by SectionBase
without it being noticed. This change makes this bug easier to notice
and fixes it where it occurred. It also made me realize that there was
some duplication of efforts in the loop that calls ::initialize. These
issues are all fixed by this change.

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

llvm-svn: 315372

This forces every user to use the new create method that returns an
Expected. This in turn propagates better error messages.

llvm-svn: 315371

This reverts commit r315363. It has a simple build failure, but more
importantly I want to confirm that unit tests run in check-all to make
sure that they don't silently break in the future.

llvm-svn: 315370

Summary: In the current implementation, we only have accurate profile count for standalone symbols. For inlined functions, we do not have entry count data because it's not available in LBR. In this patch, we use the first instruction's frequency to estimiate the function's entry count, especially for inlined functions. This may be inaccurate due to debug info in optimized code. However, this is a better estimate than the static 80/20 estimation we have in the current implementation.

Reviewers: tejohnson, davidxl

Reviewed By: tejohnson

Subscribers: sanjoy, llvm-commits, aprantl

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

llvm-svn: 315369