#
1def2579 |
| 08-Jul-2021 |
David Blaikie <dblaikie@gmail.com> |
PR51018: Remove explicit conversions from SmallString to StringRef to future-proof against C++23
C++23 will make these conversions ambiguous - so fix them to make the codebase forward-compatible wit
PR51018: Remove explicit conversions from SmallString to StringRef to future-proof against C++23
C++23 will make these conversions ambiguous - so fix them to make the codebase forward-compatible with C++23 (& a follow-up change I've made will make this ambiguous/invalid even in <C++23 so we don't regress this & it generally improves the code anyway)
show more ...
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
#
165321b3 |
| 12-May-2021 |
Tomas Matheson <tomas.matheson@arm.com> |
[MC][ELF] Emit unique sections for different flags
Global values imply flags such as readable, writable, executable for the sections that they will be placed in. Currently MC places all such entries
[MC][ELF] Emit unique sections for different flags
Global values imply flags such as readable, writable, executable for the sections that they will be placed in. Currently MC places all such entries into the same section, using the first set of flags seen. This can lead to situations in LTO where a writable global is placed in the same named section as a readable global from another file, and the section may not be marked writable.
D72194 ensures that mergeable globals with explicit sections are placed in separate sections with compatible entry size, by emitting the `unique` assembly syntax where appropriate. This change extends that approach to include section flags, so that globals with different section flags are emitted in separate unique sections.
Differential revision: https://reviews.llvm.org/D100944
show more ...
|
#
c2f819af |
| 23-May-2021 |
Philipp Krones <philipp.krones@embecosm.com> |
[MC] Refactor MCObjectFileInfo initialization and allow targets to create MCObjectFileInfo
This makes it possible for targets to define their own MCObjectFileInfo. This MCObjectFileInfo is then used
[MC] Refactor MCObjectFileInfo initialization and allow targets to create MCObjectFileInfo
This makes it possible for targets to define their own MCObjectFileInfo. This MCObjectFileInfo is then used to determine things like section alignment.
This is a follow up to D101462 and prepares for the RISCV backend defining the text section alignment depending on the enabled extensions.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D101921
show more ...
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3 |
|
#
3b8d2be5 |
| 27-Feb-2021 |
Sam Clegg <sbc@chromium.org> |
Reland: "[lld][WebAssembly] Initial support merging string data"
This change was originally landed in: 5000a1b4b9edeb9e994f2a5b36da8d48599bea49 It was reverted in: 061e071d8c9b98526f35cad55a918a4f16
Reland: "[lld][WebAssembly] Initial support merging string data"
This change was originally landed in: 5000a1b4b9edeb9e994f2a5b36da8d48599bea49 It was reverted in: 061e071d8c9b98526f35cad55a918a4f1615afd4
This change adds support for a new WASM_SEG_FLAG_STRINGS flag in the object format which works in a similar fashion to SHF_STRINGS in the ELF world.
Unlike the ELF linker this support is currently limited: - No support for SHF_MERGE (non-string merging) - Always do full tail merging ("lo" can be merged with "hello") - Only support single byte strings (p2align 0)
Like the ELF linker merging is only performed at `-O1` and above.
This fixes part of https://bugs.llvm.org/show_bug.cgi?id=48828, although crucially it doesn't not currently support debug sections because they are not represented by data segments (they are custom sections)
Differential Revision: https://reviews.llvm.org/D97657
show more ...
|
#
061e071d |
| 10-May-2021 |
Nico Weber <thakis@chromium.org> |
Revert "[lld][WebAssembly] Initial support merging string data"
This reverts commit 5000a1b4b9edeb9e994f2a5b36da8d48599bea49. Breaks tests, see https://reviews.llvm.org/D97657#2749151
Easily repros
Revert "[lld][WebAssembly] Initial support merging string data"
This reverts commit 5000a1b4b9edeb9e994f2a5b36da8d48599bea49. Breaks tests, see https://reviews.llvm.org/D97657#2749151
Easily repros locally with `ninja check-llvm-mc-webassembly`.
show more ...
|
#
5000a1b4 |
| 27-Feb-2021 |
Sam Clegg <sbc@chromium.org> |
[lld][WebAssembly] Initial support merging string data
This change adds support for a new WASM_SEG_FLAG_STRINGS flag in the object format which works in a similar fashion to SHF_STRINGS in the ELF w
[lld][WebAssembly] Initial support merging string data
This change adds support for a new WASM_SEG_FLAG_STRINGS flag in the object format which works in a similar fashion to SHF_STRINGS in the ELF world.
Unlike the ELF linker this support is currently limited: - No support for SHF_MERGE (non-string merging) - Always do full tail merging ("lo" can be merged with "hello") - Only support single byte strings (p2align 0)
Like the ELF linker merging is only performed at `-O1` and above.
This fixes part of https://bugs.llvm.org/show_bug.cgi?id=48828, although crucially it doesn't not currently support debug sections because they are not represented by data segments (they are custom sections)
Differential Revision: https://reviews.llvm.org/D97657
show more ...
|
#
632ebc4a |
| 05-May-2021 |
Philipp Krones <philipp.krones@embecosm.com> |
[MC] Untangle MCContext and MCObjectFileInfo
This untangles the MCContext and the MCObjectFileInfo. There is a circular dependency between MCContext and MCObjectFileInfo. Currently this dependency a
[MC] Untangle MCContext and MCObjectFileInfo
This untangles the MCContext and the MCObjectFileInfo. There is a circular dependency between MCContext and MCObjectFileInfo. Currently this dependency also exists during construction: You can't contruct a MOFI without a MCContext without constructing the MCContext with a dummy version of that MOFI first. This removes this dependency during construction. In a perfect world, MCObjectFileInfo wouldn't depend on MCContext at all, but only be stored in the MCContext, like other MC information. This is future work.
This also shifts/adds more information to the MCContext making it more available to the different targets. Namely:
- TargetTriple - ObjectFileType - SubtargetInfo
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D101462
show more ...
|
#
87bbf3d1 |
| 05-Mar-2021 |
Chen Zheng <czhengsz@cn.ibm.com> |
[XCOFF][DebugInfo] support DWARF for XCOFF for assembly output.
Reviewed By: jasonliu
Differential Revision: https://reviews.llvm.org/D95518
|
#
10392825 |
| 02-Mar-2021 |
Yuanfang Chen <yuanfang.chen@sony.com> |
Fix memleak for 5de2d189e6ad4
Fix typo `release` -> `reset`
|
Revision tags: llvmorg-12.0.0-rc2 |
|
#
5de2d189 |
| 23-Feb-2021 |
Yuanfang Chen <yuanfang.chen@sony.com> |
[Diagnose] Unify MCContext and LLVMContext diagnosing
The situation with inline asm/MC error reporting is kind of messy at the moment. The errors from MC layout are not reliably propagated and users
[Diagnose] Unify MCContext and LLVMContext diagnosing
The situation with inline asm/MC error reporting is kind of messy at the moment. The errors from MC layout are not reliably propagated and users have to specify an inlineasm handler separately to get inlineasm diagnose. The latter issue is not a correctness issue but could be improved.
* Kill LLVMContext inlineasm diagnose handler and migrate it to use DiagnoseInfo/DiagnoseHandler. * Introduce `DiagnoseInfoSrcMgr` to diagnose SourceMgr backed errors. This covers use cases like inlineasm, MC, and any clients using SourceMgr. * Move AsmPrinter::SrcMgrDiagInfo and its instance to MCContext. The next step is to combine MCContext::SrcMgr and MCContext::InlineSrcMgr because in all use cases, only one of them is used. * If LLVMContext is available, let MCContext uses LLVMContext's diagnose handler; if LLVMContext is not available, MCContext uses its own default diagnose handler which just prints SMDiagnostic. * Change a few clients(Clang, llc, lldb) to use the new way of reporting.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D97449
show more ...
|
#
508aa69e |
| 11-Feb-2021 |
Wouter van Oortmerssen <aardappel@gmail.com> |
[WebAssembly] Fix assert in lookup of section symbols
Fixes assert in: https://bugs.llvm.org/show_bug.cgi?id=49036
getWasmSection creates sections if they don't exist, but doesn't add them to the S
[WebAssembly] Fix assert in lookup of section symbols
Fixes assert in: https://bugs.llvm.org/show_bug.cgi?id=49036
getWasmSection creates sections if they don't exist, but doesn't add them to the Symbols table. This may cause problems in subsequent calls to getOrCreateSymbol which checks this table, the calls createSymbol assuming it doesn't exist, which then checks UsedNames and finds out it does exist, causing an assert on trying to rename a non-temp symbol.
I tried also fixing the somewhat unintuitive forced suffixing (adding `0`), but it turns out that WasmObjectWriter currently assumes these section symbols are unique, so that may have to be a separate fix: https://bugs.llvm.org/show_bug.cgi?id=49252
Also worth noting is that getWasmSection calling createSymbol may not be correct to start with, given that createSymbol seems to assume it is creating non-section symbols. But again, for a future fix.
Related: where some of this was introduced: https://github.com/llvm/llvm-project/commit/8d396acac3bc21f688ac707bb42e4698dbdcab7e
Differential Revision: https://reviews.llvm.org/D96473
show more ...
|
#
5517923b |
| 18-Feb-2021 |
Chen Zheng <czhengsz@cn.ibm.com> |
[XCOFF][NFC] make csect properties optional for getXCOFFSection
We are going to support debug sections for XCOFF. So the csect properties are not necessary. This patch makes these properties optiona
[XCOFF][NFC] make csect properties optional for getXCOFFSection
We are going to support debug sections for XCOFF. So the csect properties are not necessary. This patch makes these properties optional.
Reviewed By: hubert.reinterpretcast
Differential Revision: https://reviews.llvm.org/D95931
show more ...
|
Revision tags: llvmorg-11.1.0, llvmorg-11.1.0-rc3 |
|
#
16af9739 |
| 01-Feb-2021 |
Petr Hosek <phosek@google.com> |
[MC][ELF] Support for zero flag section groups
This change introduces support for zero flag ELF section groups to LLVM. LLVM already supports COMDAT sections, which in ELF are a special type of ELF
[MC][ELF] Support for zero flag section groups
This change introduces support for zero flag ELF section groups to LLVM. LLVM already supports COMDAT sections, which in ELF are a special type of ELF section groups. These are generally useful to enable linker GC where you want a group of sections to always travel together, that is to be either retained or discarded as a whole, but without the COMDAT semantics. Other ELF assemblers already support zero flag ELF section groups and this change helps us reach feature parity.
Differential Revision: https://reviews.llvm.org/D95851
show more ...
|
Revision tags: llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1 |
|
#
d9a0c40b |
| 21-Dec-2020 |
Fangrui Song <i@maskray.me> |
[MC] Split MCContext::createTempSymbol, default AlwaysAddSuffix to true, and add comments
CanBeUnnamed is rarely false. Splitting to a createNamedTempSymbol makes the intention clearer and matches t
[MC] Split MCContext::createTempSymbol, default AlwaysAddSuffix to true, and add comments
CanBeUnnamed is rarely false. Splitting to a createNamedTempSymbol makes the intention clearer and matches the direction of reverted r240130 (to drop the unneeded parameters).
No behavior change.
show more ...
|
#
8ffda237 |
| 21-Dec-2020 |
Fangrui Song <i@maskray.me> |
MCContext::reportError: don't call report_fatal_error
Errors from MCAssembler, MCObjectStreamer and *ObjectWriter typically cause a crash:
``` % cat c.c int bar; extern int foo __attribute__((alias
MCContext::reportError: don't call report_fatal_error
Errors from MCAssembler, MCObjectStreamer and *ObjectWriter typically cause a crash:
``` % cat c.c int bar; extern int foo __attribute__((alias("bar"))); % clang -c -fcommon c.c fatal error: error in backend: Common symbol 'bar' cannot be used in assignment expr PLEASE submit a bug report to ... Stack dump: ... ```
`LLVMTargetMachine::addPassesToEmitFile` constructs `MachineModuleInfoWrapperPass` which creates a MCContext without SourceMgr. `MCContext::reportError` calls `report_fatal_error` which gets captured by Clang `LLVMErrorHandler` and gets translated to the output above.
Since `MCContext::reportError` errors indicate user errors, such a crashing style error is inappropriate. So this patch changes `report_fatal_error` to `SourceMgr().PrintMessage`. ``` % clang -c -fcommon c.c <unknown>:0: error: Common symbol 'bar' cannot be used in assignment expr ```
Ideally we should at least recover the original filename (the line information is generally lost). That requires general improvement to MC diagnostics, because currently in many cases SMLoc information is lost.
show more ...
|
Revision tags: llvmorg-11.0.1, llvmorg-11.0.1-rc2 |
|
#
0a391060 |
| 04-Dec-2020 |
Derek Schuff <dschuff@chromium.org> |
[WebAssembly] Add Object and ObjectWriter support for wasm COMDAT sections
Allow sections to be placed into COMDAT groups, in addtion to functions and data segments.
Also make section symbols unnam
[WebAssembly] Add Object and ObjectWriter support for wasm COMDAT sections
Allow sections to be placed into COMDAT groups, in addtion to functions and data segments.
Also make section symbols unnamed, which allows sections with identical names (section names are independent of their section symbols, but previously we gave the symbols the same name as their sections, which results in collisions when sections are identically-named).
Differential Revision: https://reviews.llvm.org/D92691
show more ...
|
Revision tags: llvmorg-11.0.1-rc1 |
|
#
42d21093 |
| 09-Nov-2020 |
jasonliu <jasonliu.development@gmail.com> |
[XCOFF] Enable explicit sections on AIX
Implement mechanism to allow explicit sections to be generated on AIX.
Reviewed By: DiggerLin
Differential Revision: https://reviews.llvm.org/D88615
|
Revision tags: llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2 |
|
#
e9ac1495 |
| 11-Aug-2020 |
diggerlin <digger.llvm@gmail.com> |
[AIX][XCOFF] change the operand of branch instruction from symbol name to qualified symbol name for function declarations
SUMMARY:
1. in the patch , remove setting storageclass in function .getXCO
[AIX][XCOFF] change the operand of branch instruction from symbol name to qualified symbol name for function declarations
SUMMARY:
1. in the patch , remove setting storageclass in function .getXCOFFSection and construct function of class MCSectionXCOFF there are
XCOFF::StorageMappingClass MappingClass; XCOFF::SymbolType Type; XCOFF::StorageClass StorageClass; in the MCSectionXCOFF class, these attribute only used in the XCOFFObjectWriter, (asm path do not need the StorageClass)
we need get the value of StorageClass, Type,MappingClass before we invoke the getXCOFFSection every time.
actually , we can get the StorageClass of the MCSectionXCOFF from it's delegated symbol.
2. we also change the oprand of branch instruction from symbol name to qualify symbol name. for example change bl .foo extern .foo to bl .foo[PR] extern .foo[PR]
3. and if there is reference indirect call a function bar. we also add extern .bar[PR]
Reviewers: Jason liu, Xiangling Liao
Differential Revision: https://reviews.llvm.org/D84765
show more ...
|
#
509f5c4e |
| 29-Jul-2020 |
hgreving <hgreving@hendrik-laptop.lan> |
[MC] Fix memory leak when allocating MCInst with bump allocator
Adds the function createMCInst() to MCContext that creates a MCInst using a typed bump alloctor.
MCInst contains a SmallVector<MCOper
[MC] Fix memory leak when allocating MCInst with bump allocator
Adds the function createMCInst() to MCContext that creates a MCInst using a typed bump alloctor.
MCInst contains a SmallVector<MCOperand, 8>. The SmallVector is POD only for <= 8 operands. The default untyped bump pointer allocator of MCContext does not delete the MCInst, so if the SmallVector grows, it's a leak.
This fixes https://bugs.llvm.org/show_bug.cgi?id=46900.
show more ...
|
Revision tags: llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3 |
|
#
6d3ae365 |
| 06-Jul-2020 |
jasonliu <jasonliu.development@gmail.com> |
[XCOFF][AIX] Give symbol an internal name when desired symbol name contains invalid character(s)
Summary:
When a desired symbol name contains invalid character that the system assembler could not p
[XCOFF][AIX] Give symbol an internal name when desired symbol name contains invalid character(s)
Summary:
When a desired symbol name contains invalid character that the system assembler could not process, we need to emit .rename directive in assembly path in order for that desired symbol name to appear in the symbol table.
Reviewed By: hubert.reinterpretcast, DiggerLin, daltenty, Xiangling_L
Differential Revision: https://reviews.llvm.org/D82481
show more ...
|
Revision tags: llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1 |
|
#
7a8edcb2 |
| 29-Apr-2020 |
Sylvain Audi <sylvain.audi@ubisoft.com> |
[Clang] Restore replace_path_prefix instead of startswith
In D49466, sys::path::replace_path_prefix was used instead startswith for -f[macro/debug/file]-prefix-map options. However those were revert
[Clang] Restore replace_path_prefix instead of startswith
In D49466, sys::path::replace_path_prefix was used instead startswith for -f[macro/debug/file]-prefix-map options. However those were reverted later (commit rG3bb24bf25767ef5bbcef958b484e7a06d8689204) due to broken Windows tests.
This patch restores those replace_path_prefix calls. It also modifies the prefix matching to be case-insensitive under Windows.
Differential Revision : https://reviews.llvm.org/D76869
show more ...
|
#
86478d3d |
| 16-Apr-2020 |
bd1976llvm <Ben.Dunbobbin@sony.com> |
[MC][ELF] Put explicit section name symbols into entry size compatible sections
Ensure that symbols explicitly* assigned a section name are placed into a section with a compatible entry size.
This
[MC][ELF] Put explicit section name symbols into entry size compatible sections
Ensure that symbols explicitly* assigned a section name are placed into a section with a compatible entry size.
This is done by creating multiple sections with the same name** if incompatible symbols are explicitly given the name of an incompatible section, whilst:
- Avoiding using uniqued sections where possible (for readability and to maximize compatibly with assemblers).
- Creating as few SHF_MERGE sections as possible (for efficiency).
Given that each symbol is assigned to a section in a single pass, we must decide which section each symbol is assigned to without seeing the properties of all symbols. A stable and easy to understand assignment is desirable. The following rules facilitate this: The "generic" section for a given section name will be mergeable if the name is a mergeable "default" section name (such as .debug_str), a mergeable "implicit" section name (such as .rodata.str2.2), or MC has already created a mergeable "generic" section for the given section name (e.g. in response to a section directive in inline assembly). Otherwise, the "generic" section for a given name is non-mergeable; and, non-mergeable symbols are assigned to the "generic" section, while mergeable symbols are assigned to uniqued sections.
Terminology: "default" sections are those always created by MC initially, e.g. .text or .debug_str.
"implicit" sections are those created normally by MC in response to the symbols that it encounters, i.e. in the absence of an explicit section name assignment on the symbol, e.g. a function foo might be placed into a .text.foo section.
"generic" sections are those that are referred to when a unique section ID is not supplied, e.g. if there are multiple unique .bob sections then ".quad .bob" will reference the generic .bob section. Typically, the generic section is just the first section of a given name to be created. Default sections are always generic.
* Typically, section names might be explicitly assigned in source code using a language extension e.g. a section attribute: _attribute_ ((section ("section-name"))) - https://clang.llvm.org/docs/AttributeReference.html
** I refer to such sections as unique/uniqued sections. In assembly the ", unique," assembly syntax is used to express such sections.
Fixes https://bugs.llvm.org/show_bug.cgi?id=43457.
See https://reviews.llvm.org/D68101 for previous discussions leading to this patch.
Some minor fixes were required to LLVM's tests, for tests had been using the old behavior - which allowed for explicitly assigning globals with incompatible entry sizes to a section.
This fix relies on the ",unique ," assembly feature. This feature is not available until bintuils version 2.35 (https://sourceware.org/bugzilla/show_bug.cgi?id=25380). If the integrated assembler is not being used then we avoid using this feature for compatibility and instead try to place mergeable symbols into non-mergeable sections or issue an error otherwise.
Differential Revision: https://reviews.llvm.org/D72194
show more ...
|
#
90a63f6d |
| 15-Apr-2020 |
Fangrui Song <maskray@google.com> |
[MC] Replace MCSection*::getName() with MCSection::getName(). NFC
I plan to use MCSection::getName() in D78138. Having the function in the base class is also convenient for debugging.
Reviewed By:
[MC] Replace MCSection*::getName() with MCSection::getName(). NFC
I plan to use MCSection::getName() in D78138. Having the function in the base class is also convenient for debugging.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D78251
show more ...
|
#
7d1ff446 |
| 15-Apr-2020 |
Fangrui Song <maskray@google.com> |
[MC] Rename MCSection*::getSectionName() to getName(). NFC
A pending change will merge MCSection*::getName() to MCSection::getName().
|
#
5be42f36 |
| 07-Apr-2020 |
Sam Clegg <sbc@chromium.org> |
[WebAssembly][MC] Fix leak of std::string members in MCSymbolWasm
Summary: Fixes: https://bugs.llvm.org/show_bug.cgi?id=45452
Subscribers: dschuff, jgravelle-google, hiraditya, aheejin, sunfish, ll
[WebAssembly][MC] Fix leak of std::string members in MCSymbolWasm
Summary: Fixes: https://bugs.llvm.org/show_bug.cgi?id=45452
Subscribers: dschuff, jgravelle-google, hiraditya, aheejin, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D77627
show more ...
|