[MC] Use a stub ctor for MCAsmLayout

and replace MCAssembler::Layout with a bool.
This mostly completes "[MC] Start merging MCAsmLayout into MCAssembler".

Note: BOLT used a dummy `MCAsmLayout` to c

[MC] Use a stub ctor for MCAsmLayout

and replace MCAssembler::Layout with a bool.
This mostly completes "[MC] Start merging MCAsmLayout into MCAssembler".

Note: BOLT used a dummy `MCAsmLayout` to call `getSymbolOffset`, which
is technically not supported. There is some discussion in
https://reviews.llvm.org/D154604 .

The revert f80a4072ced41b52363c63df28fea9a649f7f89e is incorrect and
actually broke bots.

show more ...

Revert "[MC] Use a stub ctor for MCAsmLayout"

This reverts commit bbb50369a149d9a7d1f91efaaabf75c260a220c7.

This breaks BOLT.

[MC] Use a stub ctor for MCAsmLayout

and replace MCAssembler::Layout with a bool.
This mostly completes "[MC] Start merging MCAsmLayout into MCAssembler".

MCExpr::evaluateAsRelocatable: replace the MCAsmLayout parameter with MCAssembler

Continue the MCAsmLayout removal work started by 67957a45ee1ec42ae1671cdbfa0d73127346cc95.

[PowerPC] Allow absolute expressions in relocations

The Linux kernel build uses absolute expressions suffixed with @lo/@ha
relocations. This currently doesn't work for DS/DQ form instructions and
th

[PowerPC] Allow absolute expressions in relocations

The Linux kernel build uses absolute expressions suffixed with @lo/@ha
relocations. This currently doesn't work for DS/DQ form instructions and
there is no reason for it not to. It also works with GAS.
This patch allows this as long as the value is a multiple of 4/16
for DS/DQ form.

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

show more ...

[PowerPC][MC] Delete PPCMCExpr::IsDarwin

[NFC] Replace 'isDarwin' with 'IsDarwin'

Summary: Replace 'isDarwin' with 'IsDarwin' based on LLVM naming convention.

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

llvm-svn: 373852

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

[PPC64] Support "symbol@high" and "symbol@higha" symbol modifers.

Add support for the "@high" and "@higha" symbol modifiers in powerpc64 assembly.
The modifiers represent accessing the segment consi

[PPC64] Support "symbol@high" and "symbol@higha" symbol modifers.

Add support for the "@high" and "@higha" symbol modifiers in powerpc64 assembly.
The modifiers represent accessing the segment consiting of bits 16-31 of a
64-bit address/offset.

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

llvm-svn: 334855

show more ...

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line

Sort the remaining #include lines in include/... and lib/....

I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.

I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.

This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.

Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).

llvm-svn: 304787

show more ...

MC: Add target hook to control symbol quoting

llvm-svn: 239370

MC: Clean up MCExpr naming. NFC.

llvm-svn: 238634

@l and friends adjust their value depending the context used in.
For ori, they are unsigned, for addi, signed. Create a new target
expression type to handle this and evaluate Fixups accordingly.

llv

@l and friends adjust their value depending the context used in.
For ori, they are unsigned, for addi, signed. Create a new target
expression type to handle this and evaluate Fixups accordingly.

llvm-svn: 215315

show more ...

If available, pass down the Fixup object to EvaluateAsRelocatable.
At least on PowerPC, the interpretation of certain modifiers depends on
the context they appear in.

llvm-svn: 215310

Move expression visitation logic up to MCStreamer.

Remove the duplicate from MCRecordStreamer. No functionality change.

llvm-svn: 211714

Simplify the visitation of target expressions. No functionality change.

llvm-svn: 211707

[Modules] Fix potential ODR violations by sinking the DEBUG_TYPE
definition below all of the header #include lines, lib/Target/...
edition.

llvm-svn: 206842

Try harder to evaluate expressions when printing assembly.

When printing assembly we don't have a Layout object, but we can still
try to fold some constants.

Testcase by Ulrich Weigand.

llvm-svn:

Try harder to evaluate expressions when printing assembly.

When printing assembly we don't have a Layout object, but we can still
try to fold some constants.

Testcase by Ulrich Weigand.

llvm-svn: 203677

show more ...

Re-sort all of the includes with ./utils/sort_includes.py so that
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.

Also com

Re-sort all of the includes with ./utils/sort_includes.py so that
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.

Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.

llvm-svn: 198685

show more ...

Fix use of uninitialized value added in r189400 (found by MemorySanitizer)

llvm-svn: 189456

Given target assembler parsers a chance to handle variant expressions
first. Use this to turn the PPC modifiers into PPC specific expressions,
allowing them to work on constants.

llvm-svn: 189400

[PowerPC] Always use "assembler dialect" 1

A setting in MCAsmInfo defines the "assembler dialect" to use. This is used
by common code to choose between alternatives in a multi-alternative GNU
inlin

[PowerPC] Always use "assembler dialect" 1

A setting in MCAsmInfo defines the "assembler dialect" to use. This is used
by common code to choose between alternatives in a multi-alternative GNU
inline asm statement like the following:

__asm__ ("{sfe|subfe} %0,%1,%2" : "=r" (out) : "r" (in1), "r" (in2));

The meaning of these dialects is platform specific, and GCC defines those
for PowerPC to use dialect 0 for old-style (POWER) mnemonics and 1 for
new-style (PowerPC) mnemonics, like in the example above.

To be compatible with inline asm used with GCC, LLVM ought to do the same.
Specifically, this means we should always use assembler dialect 1 since
old-style mnemonics really aren't supported on any current platform.

However, the current LLVM back-end uses:
AssemblerDialect = 1; // New-Style mnemonics.
in PPCMCAsmInfoDarwin, and
AssemblerDialect = 0; // Old-Style mnemonics.
in PPCLinuxMCAsmInfo.

The Linux setting really isn't correct, we should be using new-style
mnemonics everywhere. This is changed by this commit.

Unfortunately, the setting of this variable is overloaded in the back-end
to decide whether or not we are on a Darwin target. This is done in
PPCInstPrinter (the "SyntaxVariant" is initialized from the MCAsmInfo
AssemblerDialect setting), and also in PPCMCExpr. Setting AssemblerDialect
to 1 for both Darwin and Linux no longer allows us to make this distinction.

Instead, this patch uses the MCSubtargetInfo passed to createPPCMCInstPrinter
to distinguish Darwin targets, and ignores the SyntaxVariant parameter.
As to PPCMCExpr, this patch adds an explicit isDarwin argument that needs
to be passed in by the caller when creating a target MCExpr. (To do so
this patch implicitly also reverts commit 184441.)

llvm-svn: 185858

show more ...

[PowerPC] Support @higher et.al. modifiers

This adds support for the @higher, @highera, @highest, and @highesta
modifers, including some missing relocation types.

llvm-svn: 184550

[PowerPC] Support @h modifier

This adds necessary infrastructure to support the @h modifier.
Note that all required relocation types were already present
(and unused).

This patch provides support f

[PowerPC] Support @h modifier

This adds necessary infrastructure to support the @h modifier.
Note that all required relocation types were already present
(and unused).

This patch provides support for using @h in the assembler;
it would also be possible to now use this feature in code
generated by the compiler, but this is not done yet.

llvm-svn: 184548

show more ...

[PowerPC] Rename some more VK_PPC_ enums

This renames more VK_PPC_ enums, to make them more closely reflect
the @modifier string they represent. This also prepares for adding
a bunch of new VK_PPC_

[PowerPC] Rename some more VK_PPC_ enums

This renames more VK_PPC_ enums, to make them more closely reflect
the @modifier string they represent. This also prepares for adding
a bunch of new VK_PPC_ enums in upcoming patches.

For consistency, some MO_ flags related to VK_PPC_ enums are
likewise renamed.

No change in behaviour.

llvm-svn: 184547

show more ...