[MC][AArch64] Segregate constant pool caches by size. (#86832)

If you write a 32- and a 64-bit LDR instruction that both refer to the
same constant or symbol using the = syntax:

```
ldr w0, =

[MC][AArch64] Segregate constant pool caches by size. (#86832)

If you write a 32- and a 64-bit LDR instruction that both refer to the
same constant or symbol using the = syntax:

```
ldr w0, =something
ldr x1, =something
```

then the first call to `ConstantPool::addEntry` will insert the constant
into its cache of existing entries, and the second one will find the
cache entry and reuse it. This results in a 64-bit load from a 32-bit
constant, reading nonsense into the other half of the target register.

In this patch I've done the simplest fix: include the size of the
constant pool entry as part of the key used to index the cache. So now
32- and 64-bit constant loads will never share a constant pool entry.

There's scope for doing this better, in principle: you could imagine
merging the two slots with appropriate overlap, so that the 32-bit load
loads the LSW of the 64-bit value. But that's much more complicated: you
have to take endianness into account, and maybe also adjust the size of
an existing entry. This is the simplest fix that restores correctness.

show more ...

[Alignment][NFC] Use Align in MCStreamer::emitValueToAlignment

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

[MC] De-capitalize SwitchSection. NFC

Add SwitchSection to return switchSection. The API will be removed soon.

[MC][ARM] Reuse symbol value in constant pool

Fix https://github.com/llvm/llvm-project/issues/55816

Before this patch, MCConstantExpr were reused, but MCSymbolExpr were
not. To reuse symbol value,

[MC][ARM] Reuse symbol value in constant pool

Fix https://github.com/llvm/llvm-project/issues/55816

Before this patch, MCConstantExpr were reused, but MCSymbolExpr were
not. To reuse symbol value, this patch added a DenseMap to record the
symbol value.

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

show more ...

[MC] Add MCSubtargetInfo to MCAlignFragment

In preparation for passing the MCSubtargetInfo (STI) through to writeNops
so that it can use the STI in operation at the time, we need to record the
STI i

[MC] Add MCSubtargetInfo to MCAlignFragment

In preparation for passing the MCSubtargetInfo (STI) through to writeNops
so that it can use the STI in operation at the time, we need to record the
STI in operation when a MCAlignFragment may write nops as padding. The
STI is currently unused, a further patch will pass it through to
writeNops.

There are many places that can create an MCAlignFragment, in most cases
we can find out the STI in operation at the time. In a few places this
isn't possible as we are in initialisation or finalisation, or are
emitting constant pools. When possible I've tried to find the most
appropriate existing fragment to obtain the STI from, when none is
available use the per module STI.

For constant pools we don't actually need to use EmitCodeAlign as the
constant pools are data anyway so falling through into it via an
executable NOP is no better than falling through into data padding.

This is a prerequisite for D45962 which uses the STI to emit the
appropriate NOP for the STI. Which can differ per fragment.

Note that involves an interface change to InitSections. It is now
called initSections and requires a SubtargetInfo as a parameter.

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

show more ...

[MCStreamer] De-capitalize EmitValue EmitIntValue{,InHex}

[MC] De-capitalize another set of MCStreamer::Emit* functions

Emit{ValueTo,Code}Alignment Emit{DTP,TP,GP}* EmitSymbolValue etc

[MC] De-capitalize some MCStreamer::Emit* functions

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[MC] - ConstantPools.cpp: Style consistency, remove redundant braces. NFC.

Remove braces around two, single statement "if" blocks in line with rest
of the file and the general LLVM code style. NFC,

[MC] - ConstantPools.cpp: Style consistency, remove redundant braces. NFC.

Remove braces around two, single statement "if" blocks in line with rest
of the file and the general LLVM code style. NFC, testing commit access.

llvm-svn: 341294

show more ...

Re-apply r302416: [ARM] Clear the constant pool cache on explicit .ltorg directives

Re-applying now that PR32825 which was raised on the commit this fixed up is now known to have also been fixed by

Re-apply r302416: [ARM] Clear the constant pool cache on explicit .ltorg directives

Re-applying now that PR32825 which was raised on the commit this fixed up is now known to have also been fixed by this commit.

Original commit message:
Multiple ldr pseudoinstructions with the same constant value will
reuse the same constant pool entry. However, if the constant pool
is explicitly flushed with a .ltorg directive, we should not try
to reference constants in the previous pool any longer, since they
may be out of range.

This fixes assembling hand-written assembler source which repeatedly
loads the same constant value, across a binary size larger than the
pc-relative fixup range for ldr instructions (4096 bytes). Such
assembler source already uses explicit .ltorg instructions to emit
constant pools with regular intervals. However if we try to reuse
constants emitted in earlier pools, they end up out of range.

This makes the output of the testcase match what binutils gas does
(prior to this patch, it would fail to assemble).

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

llvm-svn: 303540

show more ...

Re-apply r286006: Fix 24560: assembler does not share constant pool for same constants

Re-applying now that the open bug on this commit, PR32825, is known to be fixed.

Original commit message:

Re-apply r286006: Fix 24560: assembler does not share constant pool for same constants

Re-applying now that the open bug on this commit, PR32825, is known to be fixed.

Original commit message:
Summary: This patch returns the same label if the CP entry with the same value has been created.

Reviewers: eli.friedman, rengolin, jmolloy

Subscribers: majnemer, jmolloy, llvm-commits

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

llvm-svn: 303539

show more ...

Revert "[ARM] Clear the constant pool cache on explicit .ltorg directives"

This reverts commit r302416. This was a fixup for r286006, which has now been reverted so this doesn't apply (either in con

Revert "[ARM] Clear the constant pool cache on explicit .ltorg directives"

This reverts commit r302416. This was a fixup for r286006, which has now been reverted so this doesn't apply (either in concept or in code).

This commit itself has no problems, but the underlying issue it was fixing has now disappeared from the codebase.

llvm-svn: 303536

show more ...

Revert "Fix 24560: assembler does not share constant pool for same constants"

This reverts commit r286006. It caused PR32825 and wasn't fixed.

llvm-svn: 303535

[ARM] Clear the constant pool cache on explicit .ltorg directives

Multiple ldr pseudoinstructions with the same constant value will
reuse the same constant pool entry. However, if the constant pool

[ARM] Clear the constant pool cache on explicit .ltorg directives

Multiple ldr pseudoinstructions with the same constant value will
reuse the same constant pool entry. However, if the constant pool
is explicitly flushed with a .ltorg directive, we should not try
to reference constants in the previous pool any longer, since they
may be out of range.

This fixes assembling hand-written assembler source which repeatedly
loads the same constant value, across a binary size larger than the
pc-relative fixup range for ldr instructions (4096 bytes). Such
assembler source already uses explicit .ltorg instructions to emit
constant pools with regular intervals. However if we try to reuse
constants emitted in earlier pools, they end up out of range.

This makes the output of the testcase match what binutils gas does
(prior to this patch, it would fail to assemble).

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

llvm-svn: 302416

show more ...

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

llvm-svn: 294369

Fix 24560: assembler does not share constant pool for same constants

Summary: This patch returns the same label if the CP entry with the same value has been created.

Reviewers: eli.friedman, rengo

Fix 24560: assembler does not share constant pool for same constants

Summary: This patch returns the same label if the CP entry with the same value has been created.

Reviewers: eli.friedman, rengolin, jmolloy

Subscribers: majnemer, jmolloy, llvm-commits

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

llvm-svn: 286006

show more ...

Tidy the calls to getCurrentSection().first -> getCurrentSectionOnly to help
readability a bit.

llvm-svn: 284202

Apply clang-tidy's modernize-loop-convert to lib/MC.

Only minor manual fixes. No functionality change intended.

llvm-svn: 273814

[ARM,AArch64] Store source location of asm constant pool entries

Storing the source location of the expression that created a constant pool
entry allows us to emit better error messages if we later

[ARM,AArch64] Store source location of asm constant pool entries

Storing the source location of the expression that created a constant pool
entry allows us to emit better error messages if we later discover that the
expression cannot be represented by a relocation.

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

llvm-svn: 253220

show more ...

MC: Clean up MCExpr naming. NFC.

llvm-svn: 238634

Move alignment from MCSectionData to MCSection.

This starts merging MCSection and MCSectionData.

There are a few issues with the current split between MCSection and
MCSectionData.

* It optimizes t

Move alignment from MCSectionData to MCSection.

This starts merging MCSection and MCSectionData.

There are a few issues with the current split between MCSection and
MCSectionData.

* It optimizes the the not as important case. We want the production
of .o files to be really fast, but the split puts the information used
for .o emission in a separate data structure.

* The ELF/COFF/MachO hierarchy is not represented in MCSectionData,
leading to some ad-hoc ways to represent the various flags.

* It makes it harder to remember where each item is.

The attached patch starts merging the two by moving the alignment from
MCSectionData to MCSection.

Most of the patch is actually just dropping 'const', since
MCSectionData is mutable, but MCSection was not.

llvm-svn: 237936

show more ...

MC: Clean up method names in MCContext.

The naming was a mish-mash of old and new style. Update to be consistent
with the new. NFC.

llvm-svn: 237594

[cleanup] Re-sort all the #include lines in LLVM using
utils/sort_includes.py.

I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the Inst

[cleanup] Re-sort all the #include lines in LLVM using
utils/sort_includes.py.

I clearly haven't done this in a while, so more changed than usual. This
even uncovered a missing include from the InstrProf library that I've
added. No functionality changed here, just mechanical cleanup of the
include order.

llvm-svn: 225974

show more ...

Fix build failure on windows

Add explicit constructor to struct instead of using brace initialization.

llvm-svn: 213389