[MC] Remove unused includes (NFC) (#116317)

Identified with misc-include-cleaner.

Revert "[MC] Compute fragment offsets eagerly"

This reverts commit be5a845e4c29aadb513ae6e5e2879dccf37efdbb.

This causes large code size regressions, which were not present
in the initial version o

Revert "[MC] Compute fragment offsets eagerly"

This reverts commit be5a845e4c29aadb513ae6e5e2879dccf37efdbb.

This causes large code size regressions, which were not present
in the initial version of this change.

show more ...

[MC] Compute fragment offsets eagerly

This builds on top of commit 9d0754ada5dbbc0c009bcc2f7824488419cc5530
("[MC] Relax fragments eagerly") and relaxes fragments eagerly to
eliminate MCSection::Has

[MC] Compute fragment offsets eagerly

This builds on top of commit 9d0754ada5dbbc0c009bcc2f7824488419cc5530
("[MC] Relax fragments eagerly") and relaxes fragments eagerly to
eliminate MCSection::HasLayout and `getFragmentOffset` overhead. The
approach is slightly different from
1a47f3f3db66589c11f8ddacfeaecc03fb80c510 and has less performance
benefit.

The new layout algorithm also addresses the following problems:

* Size change of MCFillFragment/MCOrgFragment did not influence the
fixed-point iteration, which could be problematic for contrived cases.
* The `invalid number of bytes` error was reported too early. Since
`.zero A-B` might have temporary negative values in the first few
iterations.
* X86AsmBackend::finishLayout performed only one iteration, which might
not converge. In addition, the removed `#ifndef NDEBUG` code (disabled
by default) in X86AsmBackend::finishLayout was problematic, as !NDEBUG
and NDEBUG builds evaluated fragment offsets at different times before
this patch.
* The computed layout for relax-recompute-align.s is optimal now.

Builds with many text sections (e.g. full LTO) shall observe a decrease
in compile time while the new algorithm could be slightly slower for
some -O0 -g projects.

Aligned bundling from the deprecated PNaCl placed constraints how we can
perform iteration.

show more ...

Revert "[MC] Compute fragment offsets eagerly"

This reverts commit 1a47f3f3db66589c11f8ddacfeaecc03fb80c510.

Fix #100283

This commit is actually a trigger of other preexisting problems:

* Size ch

Revert "[MC] Compute fragment offsets eagerly"

This reverts commit 1a47f3f3db66589c11f8ddacfeaecc03fb80c510.

Fix #100283

This commit is actually a trigger of other preexisting problems:

* Size change of fill fragments does not influence the fixed-point iteration.
* The `invalid number of bytes` error is reported too early. Since
`.zero A-B` might have temporary negative values in the first few
iterations.

However, the problems appeared at least "benign" (did not affect the
Linux kernel builds) before this commit.

show more ...

[MC] Compute fragment offsets eagerly

This builds on top of commit 9d0754ada5dbbc0c009bcc2f7824488419cc5530
("[MC] Relax fragments eagerly") and relaxes fragments eagerly to
eliminate MCSection::Has

[MC] Compute fragment offsets eagerly

This builds on top of commit 9d0754ada5dbbc0c009bcc2f7824488419cc5530
("[MC] Relax fragments eagerly") and relaxes fragments eagerly to
eliminate MCSection::HasLayout and `getFragmentOffset` overhead.

Note: The removed `#ifndef NDEBUG` code (disabled by default) in
X86AsmBackend::finishLayout was problematic, as (a) !NDEBUG and NDEBUG
builds evaluated fragment offsets at different times before this patch
(b) one iteration might not be sufficient to converge. There might be
some edge cases that it did not handle. Anyhow, this patch probably
makes it work for more cases.

show more ...

[MC] Ensure subsections have a MCDataFragment

Similar to 21fac2d1d060b0f9b11a746718e58d4cd1ee97e5 for sections. This
makes it feasible to cache the current fragment in MCStreamer.

[MC] Make MCSection::isVirtualSection non-virtual (#96920)

This method is called once per encoded instruction, but never changes
throughout the lifetime of a section. Store this information as a bi

[MC] Make MCSection::isVirtualSection non-virtual (#96920)

This method is called once per encoded instruction, but never changes
throughout the lifetime of a section. Store this information as a bit
flag in the MCSection instead.

show more ...

[MC] Remove remnant code related to pending labels

[MC] Remove pending labels

This commit removes the complexity introduced by pending labels in
https://reviews.llvm.org/D5915 by using a simpler approach. D5915 aimed
to ensure padding placement befo

[MC] Remove pending labels

This commit removes the complexity introduced by pending labels in
https://reviews.llvm.org/D5915 by using a simpler approach. D5915 aimed
to ensure padding placement before `.Ltmp0` for the following code, but
at the cost of expensive per-instruction `flushPendingLabels`.

```
// similar to llvm/test/MC/X86/AlignedBundling/labeloffset.s
.bundle_lock align_to_end
calll .L0$pb
.bundle_unlock
.L0$pb:
popl %eax
.Ltmp0: //// padding should be inserted before this label instead of after
addl $_GLOBAL_OFFSET_TABLE_+(.Ltmp0-.L0$pb), %eax
```

(D5915 was adjusted by https://reviews.llvm.org/D8072 and
https://reviews.llvm.org/D71368)

This patch achieves the same goal by setting the offset of the empty
MCDataFragment (`Prev`) in `layoutBundle`. This eliminates the need for
pending labels and simplifies the code.

llvm/test/MC/MachO/pending-labels.s (D71368): relocation symbols are
changed, but the result is still supported by linkers.

show more ...

[MC] Remove the Parent parameter from MCFragment ctor callers. NFC

[MC] Remove SectionKind from MCSection (#96067)

There are only three actual uses of the section kind in MCSection:
isText(), XCOFF, and WebAssembly. Store isText() in the MCSection, and
store othe

[MC] Remove SectionKind from MCSection (#96067)

There are only three actual uses of the section kind in MCSection:
isText(), XCOFF, and WebAssembly. Store isText() in the MCSection, and
store other info in the actual section variants where required.

ELF and COFF flags also encode all relevant information, so for these
two section variants, remove the SectionKind parameter entirely.

This allows to remove the string switch (which is unnecessary and
inaccurate) from createELFSectionImpl. This was introduced in
[D133456](https://reviews.llvm.org/D133456), but apparently, it was
never hit for non-writable sections anyway and the resulting kind was
never used.

show more ...

[MC] Aligned bundling: remove special handling for RelaxAll

When both aligned bundling and RelaxAll are enabled, bundle padding is
directly written into fragments (https://reviews.llvm.org/D8072).
(

[MC] Aligned bundling: remove special handling for RelaxAll

When both aligned bundling and RelaxAll are enabled, bundle padding is
directly written into fragments (https://reviews.llvm.org/D8072).
(The original motivation was memory usage, which has been achieved from
different angles with recent assembler improvement).

The code presents challenges with the work to replace fragment
representation (e.g. #94950 #95077). This patch removes the special
handling. RelaxAll still works but the behavior seems slightly different
as revealed by 2 changed tests. However, most `-mc-relax-all` tests are
unchanged.

RelaxAll used to be the default for clang -O0. This mode has significant
code size drawbacks and newer Clang doesn't use it (#90013).

---

flushPendingLabels: The FOffset parameter can be removed: pending labels
will be assigned to the incoming fragment at offset 0.

Pull Request: https://github.com/llvm/llvm-project/pull/95188

show more ...

[MC] flushPendingLabels: revert setAtom change

The setAtom call introduced by e17bc023f4e5b79f08bfc7f624f8ff0f0cf17ce4
was due to my misunderstanding of flushPendingLabels
(see https://discourse.llv

[MC] flushPendingLabels: revert setAtom change

The setAtom call introduced by e17bc023f4e5b79f08bfc7f624f8ff0f0cf17ce4
was due to my misunderstanding of flushPendingLabels
(see https://discourse.llvm.org/t/mc-removing-aligned-bundling-support/79518).

When evaluating `.quad x-y`,
MCExpr.cpp:AttemptToFoldSymbolOffsetDifference gives different results
at parse time and layout time because the `if (FA->getAtom() ==
FB.getAtom())` condition in isSymbolRefDifferenceFullyResolvedImpl only
works when `setAtom` with a non-null pointer has been called. Calling
setAtom in flushPendingLabels does not help anything.

show more ...

[MC] Replace fragment ilist with singly-linked lists

Fragments are allocated with `operator new` and stored in an ilist with
Prev/Next/Parent pointers. A more efficient representation would be an
ar

[MC] Replace fragment ilist with singly-linked lists

Fragments are allocated with `operator new` and stored in an ilist with
Prev/Next/Parent pointers. A more efficient representation would be an
array of fragments without the overhead of Prev/Next pointers.

As the first step, replace ilist with singly-linked lists.

* `getPrevNode` uses have been eliminated by previous changes.
* The last use of the `Prev` pointer remains: for each subsection, there is an insertion point and
the current insertion point is stored at `CurInsertionPoint`.
* `HexagonAsmBackend::finishLayout` needs a backward iterator. Save all
fragments within `Frags`. Hexagon programs are usually small, and the
performance does not matter that much.

To eliminate `Prev`, change the subsection representation to
singly-linked lists for subsections and a pointer to the active
singly-linked list. The fragments from all subsections will be chained
together at layout time.

Since fragment lists are disconnected before layout time, we can remove
`MCFragment::SubsectionNumber` (https://reviews.llvm.org/D69411). The
current implementation of `AttemptToFoldSymbolOffsetDifference` requires
future improvement for robustness.

Pull Request: https://github.com/llvm/llvm-project/pull/95077

show more ...

[MC] Remove getFragmentList uses. NFC

[MC] Relax fragments eagerly

Lazy relaxation caused hash table lookups (`getFragmentOffset`) and
complex use/compute interdependencies. Some expressions involding
forward declared symbols (e.g. `sub

[MC] Relax fragments eagerly

Lazy relaxation caused hash table lookups (`getFragmentOffset`) and
complex use/compute interdependencies. Some expressions involding
forward declared symbols (e.g. `subsection-if.s`) cannot be computed.
Recursion detection requires complex `IsBeingLaidOut`
(https://reviews.llvm.org/D79570).

D76114's `invalidateFragmentsFrom` makes lazy relaxation even less
useful.

Switch to eager relaxation to greatly simplify code and resolve these
issues. This change also removes a `getPrevNode` use, which makes it
more feasible to replace the fragment representation, which might yield
a large peak RSS win.

Minor downsides: The number of section relaxations may increase (offset
by avoiding the hash table lookup). For relax-recompute-align.s, the
computed layout is not optimal.

show more ...

[MC] MCSection::dump: print section name

[MC] flushPendingLabels: set Atom for new fragment after D71368

Fixes: c26c5e47ab9ca60835f191c90fa751e9a7dd0f3d (essentially a no-op)

The newly created MCDataFragment should inherit Atom (see
MCMac

[MC] flushPendingLabels: set Atom for new fragment after D71368

Fixes: c26c5e47ab9ca60835f191c90fa751e9a7dd0f3d (essentially a no-op)

The newly created MCDataFragment should inherit Atom (see
MCMachOStreamer::finishImpl). To the best of my knowledge, this change cannot be
tested at present, but this is important to ensure
MCExpr.cpp:AttemptToFoldSymbolOffsetDifference gives the same result in case we
evaluate the expression again with a MCAsmLayout.

In the following case,
```
.section __DATA,xray_instr_map
lxray_sleds_start1:
.space 16
Lxray_sleds_end1:
.section __DATA,xray_fn_idx
.quad (Lxray_sleds_end1-lxray_sleds_start1)>>4 // can be folded without a MCAsmLayout
```

When we have a MCAsmLayout, without this change, evaluating
(Lxray_sleds_end1-lxray_sleds_start1)>>4 again will fail due to
`FA->getAtom() == nullptr && FB.getAtom() != nullptr` in
MachObjectWriter::isSymbolRefDifferenceFullyResolvedImpl, called by
AttemptToFoldSymbolOffsetDifference.

show more ...

[MC] flushPendingLabels: set Atom for new fragment after D71368

The newly created MCDataFragment should inherit Atom (see
MCMachOStreamer::finishImpl). I cannot think of a case to test the
behavior,

[MC] flushPendingLabels: set Atom for new fragment after D71368

The newly created MCDataFragment should inherit Atom (see
MCMachOStreamer::finishImpl). I cannot think of a case to test the
behavior, but this is one step towards folding the Mach-O label
difference below and making Mach-O more similar to ELF.

```
.section __DATA,xray_instr_map
lxray_sleds_start1:
.space 16
Lxray_sleds_end1:
.section __DATA,xray_fn_idx
.quad (Lxray_sleds_end1-lxray_sleds_start1)>>4 // error: expected relocatable expression // Mach-O
```

show more ...

[MC] Simplify flushPendingLabels. NFC

Cleanup LLVMMC headers

There's a few relevant forward declarations in there that may require downstream
adding explicit includes:

llvm/MC/MCContext.h no longer includes llvm/BinaryFormat/ELF.h, llv

Cleanup LLVMMC headers

There's a few relevant forward declarations in there that may require downstream
adding explicit includes:

llvm/MC/MCContext.h no longer includes llvm/BinaryFormat/ELF.h, llvm/MC/MCSubtargetInfo.h, llvm/MC/MCTargetOptions.h
llvm/MC/MCObjectStreamer.h no longer include llvm/MC/MCAssembler.h
llvm/MC/MCAssembler.h no longer includes llvm/MC/MCFixup.h, llvm/MC/MCFragment.h

Counting preprocessed lines required to rebuild llvm-project on my setup:
before: 1052436830
after: 1049293745

Which is significant and backs up the change in addition to the usual benefits of
decreasing coupling between headers and compilation units.

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D119244

show more ...

[llvm] Use llvm::lower_bound and llvm::upper_bound (NFC)

[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 ...

[MC] Resolve the difference of symbols in consecutive MCDataFragements

Try to resolve the difference of two symbols in consecutive MCDataFragments.
This is important for an idiom like "foo:instr; .i

[MC] Resolve the difference of symbols in consecutive MCDataFragements

Try to resolve the difference of two symbols in consecutive MCDataFragments.
This is important for an idiom like "foo:instr; .if . - foo; instr; .endif"
(https://bugs.llvm.org/show_bug.cgi?id=43795).

Reviewed By: nickdesaulniers

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

show more ...

[MC][COFF][ELF] Reject instructions in IMAGE_SCN_CNT_UNINITIALIZED_DATA/SHT_NOBITS sections

For `.bss; nop`, MC inappropriately calls abort() (via report_fatal_error()) with a message
`cannot have f

[MC][COFF][ELF] Reject instructions in IMAGE_SCN_CNT_UNINITIALIZED_DATA/SHT_NOBITS sections

For `.bss; nop`, MC inappropriately calls abort() (via report_fatal_error()) with a message
`cannot have fixups in virtual section!`
It is a bug to crash for invalid user input. Fix it by erroring out early in EmitInstToData().

Similarly, emitIntValue() in a virtual section (SHT_NOBITS in ELF) can crash with the mssage
`non-zero initializer found in section '.bss'` (see D4199)
It'd be nice to report the location but so many directives can call emitIntValue()
and it is difficult to track every location.
Note, COFF does not crash because MCAssembler::writeSectionData() is not
called for an IMAGE_SCN_CNT_UNINITIALIZED_DATA section.

Note, GNU as' arm64 backend reports ``Error: attempt to store non-zero value in section `.bss'``
for a non-zero .inst but fails to do so for other instructions.
We simply reject all instructions, even if the encoding is all zeros.

The Mach-O counterpart is D48517 (see `test/MC/MachO/zerofill-text.s`)

Reviewed By: rnk, skan

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

show more ...