Simplify selectELFSectionForGlobal by pulling out the entry size
determination for mergeable sections into a small static function.

llvm-svn: 338469

Tidy up logic around unique section name creation and remove a
mostly unused variable.

llvm-svn: 338468

Revert "[COFF] Use comdat shared constants for MinGW as well"

This reverts commit r337951.

While that kind of shared constant generally works fine in a MinGW
setting, it broke some cases of inline

Revert "[COFF] Use comdat shared constants for MinGW as well"

This reverts commit r337951.

While that kind of shared constant generally works fine in a MinGW
setting, it broke some cases of inline assembly that worked before:

$ cat const-asm.c
int MULH(int a, int b) {
int rt, dummy;
__asm__ (
"imull %3"
:"=d"(rt), "=a"(dummy)
:"a"(a), "rm"(b)
);
return rt;
}
int func(int a) {
return MULH(a, 1);
}
$ clang -target x86_64-win32-gnu -c const-asm.c -O2
const-asm.c:4:9: error: invalid variant '00000001'
"imull %3"
^
<inline asm>:1:15: note: instantiated into assembly here
imull __real@00000001(%rip)
^

A similar error is produced for i686 as well. The same test with a
target of x86_64-win32-msvc or i686-win32-msvc works fine.

llvm-svn: 338018

show more ...

[COFF] Use comdat shared constants for MinGW as well

GNU binutils tools have no problems with this kind of shared constants,
provided that we actually hook it up completely in AsmPrinter and
produce

[COFF] Use comdat shared constants for MinGW as well

GNU binutils tools have no problems with this kind of shared constants,
provided that we actually hook it up completely in AsmPrinter and
produce a global symbol.

This effectively reverts SVN r335918 by hooking the rest of it up
properly.

This feature was implemented originally in SVN r213006, with no reason
for why it can't be used for MinGW other than the fact that GCC doesn't
do it while MSVC does.

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

llvm-svn: 337951

show more ...

[MC] Add a separate flag for skipping comdat constant sections for MinGW. NFC.

This actually has nothing to do with the associative comdat sections
that aren't supported by GNU binutils ld.

Clarify

[MC] Add a separate flag for skipping comdat constant sections for MinGW. NFC.

This actually has nothing to do with the associative comdat sections
that aren't supported by GNU binutils ld.

Clarify the comments from SVN r335918 and use a separate flag for it.

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

llvm-svn: 337757

show more ...

Recommit r335794 "Add support for generating a call graph profile from Branch Frequency Info." with fix for removed functions.

llvm-svn: 337140

[COFF] Fix constant sharing regression for MinGW

This fixes a regression since SVN r334523, where the object files
built targeting MinGW were rejected by GNU binutils tools. Prior to
that commit, we

[COFF] Fix constant sharing regression for MinGW

This fixes a regression since SVN r334523, where the object files
built targeting MinGW were rejected by GNU binutils tools. Prior to
that commit, we only put constants in comdat for MSVC configurations.

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

llvm-svn: 335918

show more ...

Revert "Add support for generating a call graph profile from Branch Frequency Info."

This reverts commits r335794 and r335797. Breaks ThinLTO+FDO selfhost.

llvm-svn: 335851

Add support for generating a call graph profile from Branch Frequency Info.

=== Generating the CG Profile ===

The CGProfile module pass simply gets the block profile count for each BB and scans for

Add support for generating a call graph profile from Branch Frequency Info.

=== Generating the CG Profile ===

The CGProfile module pass simply gets the block profile count for each BB and scans for call instructions. For each call instruction it adds an edge from the current function to the called function with the current BB block profile count as the weight.

After scanning all the functions, it generates an appending module flag containing the data. The format looks like:
```
!llvm.module.flags = !{!0}

!0 = !{i32 5, !"CG Profile", !1}
!1 = !{!2, !3, !4} ; List of edges
!2 = !{void ()* @a, void ()* @b, i64 32} ; Edge from a to b with a weight of 32
!3 = !{void (i1)* @freq, void ()* @a, i64 11}
!4 = !{void (i1)* @freq, void ()* @b, i64 20}
```

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

llvm-svn: 335794

show more ...

Revert r335306 (and r335314) - the Call Graph Profile pass.

This is the first pass in the main pipeline to use the legacy PM's
ability to run function analyses "on demand". Unfortunately, it turns
o

Revert r335306 (and r335314) - the Call Graph Profile pass.

This is the first pass in the main pipeline to use the legacy PM's
ability to run function analyses "on demand". Unfortunately, it turns
out there are bugs in that somewhat-hacky approach. At the very least,
it leaks memory and doesn't support -debug-pass=Structure. Unclear if
there are larger issues or not, but this should get the sanitizer bots
back to green by fixing the memory leaks.

llvm-svn: 335320

show more ...

[Instrumentation] Add Call Graph Profile pass

This patch adds support for generating a call graph profile from Branch Frequency Info.

The CGProfile module pass simply gets the block profile count f

[Instrumentation] Add Call Graph Profile pass

This patch adds support for generating a call graph profile from Branch Frequency Info.

The CGProfile module pass simply gets the block profile count for each BB and scans for call instructions. For each call instruction it adds an edge from the current function to the called function with the current BB block profile count as the weight.

After scanning all the functions, it generates an appending module flag containing the data. The format looks like:

!llvm.module.flags = !{!0}

!0 = !{i32 5, !"CG Profile", !1}
!1 = !{!2, !3, !4} ; List of edges
!2 = !{void ()* @a, void ()* @b, i64 32} ; Edge from a to b with a weight of 32
!3 = !{void (i1)* @freq, void ()* @a, i64 11}
!4 = !{void (i1)* @freq, void ()* @b, i64 20}

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

llvm-svn: 335306

show more ...

[X86] Fix 32-bit mingw comdat names, only add one underscore

llvm-svn: 335304

[mingw] Fix GCC ABI compatibility for comdat things

Summary:
GCC and the binutils COFF linker do comdats differently from MSVC.
If we want to be ABI compatible, we have to do what they do, which is

[mingw] Fix GCC ABI compatibility for comdat things

Summary:
GCC and the binutils COFF linker do comdats differently from MSVC.
If we want to be ABI compatible, we have to do what they do, which is to
emit unique section names like ".text$_Z3foov" instead of short section
names like ".text". Otherwise, the binutils linker gets confused and
reports multiple definition errors when two object files from GCC and
Clang containing the same inline function are linked together.

The best description of the issue is probably at
https://github.com/Alexpux/MINGW-packages/issues/1677, we don't seem to
have a good one in our tracker.

I fixed up the .pdata and .xdata sections needed everywhere other than
32-bit x86. GCC doesn't use associative comdats for those, it appears to
rely on the section name.

Reviewers: smeenai, compnerd, mstorsjo, martell, mati865

Subscribers: llvm-commits, hiraditya

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

llvm-svn: 335286

show more ...

Add some explanatory text to the associated symbol support.

llvm-svn: 335207

[WebAssembly] Ignore explicit section names for functions

WebAssembly doesn't support more than one function per section
and we rely on function sections being unique. This change ignores
the sectio

[WebAssembly] Ignore explicit section names for functions

WebAssembly doesn't support more than one function per section
and we rely on function sections being unique. This change ignores
the section provided by the function to avoid two functions being
in the same section.

Without this change the object writer produces the following
error for this test:
LLVM ERROR: section already has a defining function: baz

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

llvm-svn: 334752

show more ...

[MS][ARM64] Hoist __ImageBase handling into TargetLoweringObjectFileCOFF

All COFF targets should use @IMGREL32 relocations for symbol differences
against __ImageBase. Do the same for getSectionForCo

[MS][ARM64] Hoist __ImageBase handling into TargetLoweringObjectFileCOFF

All COFF targets should use @IMGREL32 relocations for symbol differences
against __ImageBase. Do the same for getSectionForConstant, so that
immediates lowered to globals get merged across TUs.

Patch by Chris January

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

llvm-svn: 334523

show more ...

Tidy comment up a bit.

llvm-svn: 332687

Fix small grammar-o.

llvm-svn: 332522

Remove unused argument from emitModuleMetadata.

NFCI.

llvm-svn: 330470

[MachO] Emit Weak ReadOnlyWithRel to ConstDataSection

Summary:
Darwin dynamic linker can handle weak symbols in ConstDataSection.
ReadonReadOnlyWithRel symbols should be emitted in ConstDataSection

[MachO] Emit Weak ReadOnlyWithRel to ConstDataSection

Summary:
Darwin dynamic linker can handle weak symbols in ConstDataSection.
ReadonReadOnlyWithRel symbols should be emitted in ConstDataSection
instead of normal DataSection.

rdar://problem/39298457

Reviewers: dexonsmith, kledzik

Subscribers: llvm-commits

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

llvm-svn: 329752

show more ...

CodeGen: support an extension to pass linker options on ELF

Introduce an extension to support passing linker options to the linker.
These would be ignored by older linkers, but newer linkers which s

CodeGen: support an extension to pass linker options on ELF

Introduce an extension to support passing linker options to the linker.
These would be ignored by older linkers, but newer linkers which support
this feature would be able to process the linker.

Emit a special discarded section `.linker-option`. The content of this
section is a pair of strings (key, value). The key is a type identifier for
the parameter. This allows for an argument free parameter that will be
processed by the linker with the value being the parameter. As an example,
`lib` identifies a library to be linked against, traditionally the `-l`
argument for Unix-based linkers with the parameter being the library name.

Thanks to James Henderson, Cary Coutant, Rafael Espinolda, Sean Silva
for the valuable discussion on the design of this feature.

llvm-svn: 323783

show more ...

CodeGen: handle llvm.used properly for COFF

`llvm.used` contains a list of pointers to named values which the
compiler, assembler, and linker are required to treat as if there is a
reference that th

CodeGen: handle llvm.used properly for COFF

`llvm.used` contains a list of pointers to named values which the
compiler, assembler, and linker are required to treat as if there is a
reference that they cannot see. Ensure that the symbols are preserved
by adding an explicit `-include` reference to the linker command.

llvm-svn: 323017

show more ...

[WebAssembly] Add COMDAT support

This adds COMDAT support to the Wasm object-file format.
Spec: https://github.com/WebAssembly/tool-conventions/pull/31

Corresponding LLD change:
https://bugs.llvm.o

[WebAssembly] Add COMDAT support

This adds COMDAT support to the Wasm object-file format.
Spec: https://github.com/WebAssembly/tool-conventions/pull/31

Corresponding LLD change:
https://bugs.llvm.org/show_bug.cgi?id=35533, and D40845

Patch by Nicholas Wilson

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

llvm-svn: 322135

show more ...

[WebAssembly] Implement @llvm.global_ctors and @llvm.global_dtors

Summary:
- lowers @llvm.global_dtors by adding @llvm.global_ctors
functions which register the destructors with `__cxa_atexit`.
-

[WebAssembly] Implement @llvm.global_ctors and @llvm.global_dtors

Summary:
- lowers @llvm.global_dtors by adding @llvm.global_ctors
functions which register the destructors with `__cxa_atexit`.
- impements @llvm.global_ctors with wasm start functions and linker metadata

See [here](https://github.com/WebAssembly/tool-conventions/issues/25) for more background.

Subscribers: jfb, dschuff, mgorny, jgravelle-google, aheejin, sunfish

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

llvm-svn: 320774

show more ...

[WebAssembly] section kind can be code

Currently, when creating a named section, the Wasm
frontend forces it to use `SectionKind::Data`, whereas
in fact C++ does generate code sections with custom
n

[WebAssembly] section kind can be code

Currently, when creating a named section, the Wasm
frontend forces it to use `SectionKind::Data`, whereas
in fact C++ does generate code sections with custom
names.

Patch by Nicholas Wilson

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

llvm-svn: 320002

show more ...