Use drop_begin (NFC)

[llvm] Use value instead of getValue (NFC)

[ms] [llvm-ml] Add support for the remaining binary named operators

Finish adding support for the remaining binary named operators in expression context: XOR, SHL, and SHR.

Differential Revision: h

[ms] [llvm-ml] Add support for the remaining binary named operators

Finish adding support for the remaining binary named operators in expression context: XOR, SHL, and SHR.

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

show more ...

[ms] [llvm-ml] Add support for anonymous labels (`@@`, `@B`, `@F`)

ml.exe and ml64.exe support the use of anonymous labels, with @B and @F referring to the previous and next anonymous label respecti

[ms] [llvm-ml] Add support for anonymous labels (`@@`, `@B`, `@F`)

ml.exe and ml64.exe support the use of anonymous labels, with @B and @F referring to the previous and next anonymous label respectively.

We add similar support to llvm-ml, with the exception that we are unable to emit an error message for an @F expression not followed by a @@ label.

Reviewed By: rnk

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

show more ...

[llvm] Don't use Optional::hasValue (NFC)

This patch replaces Optional::hasValue with the implicit cast to bool
in conditionals only.

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

[llvm] Don't use Optional::hasValue (NFC)

[MC] De-capitalize MCStreamer functions

Follow-up to c031378ce01b8485ba0ef486654bc9393c4ac024 .
The class is mostly consistent now.

[MC] Change EndOfStatement "unexpected tokens in .xxx directive " to "expected newline"

[MC] Lower case the first letter of EmitCOFF* EmitWin* EmitCV*. NFC

[llvm-ml] Add support for extern proc

EXTERN PROC isn't really well documented in MSVC, so after poking around
it seems as if it's just a regular extern symbol.

Interestingly enough, under MSVC the

[llvm-ml] Add support for extern proc

EXTERN PROC isn't really well documented in MSVC, so after poking around
it seems as if it's just a regular extern symbol.

Interestingly enough, under MSVC the following is allowed:

extern foo:proc

mov eax, foo

MSVC will output:

mov eax, 0

while llvm-ml will currently output:

mov eax, dword ptr [foo]

(since foo is an extern)

Arguably, llvm-ml's output makes more sense, even though it's
inconsistent with MSVC ml. However, since moving an extern proc symbol
to a register doesn't really make sense in the first place, we'll treat
it as undefined behavior for now.

Reviewed By: epastor

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

show more ...

[llvm-ml] Implement support for MASM's extern directive

The EXTERN keyword defines external symbols in MASM.

Credit goes to epastor@ for implementing most of the logic; I (ayzhao@)
added some bugfi

[llvm-ml] Implement support for MASM's extern directive

The EXTERN keyword defines external symbols in MASM.

Credit goes to epastor@ for implementing most of the logic; I (ayzhao@)
added some bugfixes and tests.

[0]: https://docs.microsoft.com/en-us/cpp/assembler/masm/extern-masm?view=msvc-170

Reviewed By: epastor

Submitted By: epastor

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

show more ...

[Support/Hash functions] Change the `final()` and `result()` of the hashing functions to return an array of bytes

Returning `std::array<uint8_t, N>` is better ergonomics for the hashing functions us

[Support/Hash functions] Change the `final()` and `result()` of the hashing functions to return an array of bytes

Returning `std::array<uint8_t, N>` is better ergonomics for the hashing functions usage, instead of a `StringRef`:

* When returning `StringRef`, client code is "jumping through hoops" to do string manipulations instead of dealing with fixed array of bytes directly, which is more natural
* Returning `std::array<uint8_t, N>` avoids the need for the hasher classes to keep a field just for the purpose of wrapping it and returning it as a `StringRef`

As part of this patch also:

* Introduce `TruncatedBLAKE3` which is useful for using BLAKE3 as the hasher type for `HashBuilder` with non-default hash sizes.
* Make `MD5Result` inherit from `std::array<uint8_t, 16>` which improves & simplifies its API.

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

show more ...

[MC] Fix letter case of some MCSection member functions

Cleanup MCParser headers

As usual with that header cleanup series, some implicit dependencies now need to
be explicit:

llvm/MC/MCParser/MCAsmParser.h no longer includes llvm/MC/MCParser/MCAsmLexer.

Cleanup MCParser headers

As usual with that header cleanup series, some implicit dependencies now need to
be explicit:

llvm/MC/MCParser/MCAsmParser.h no longer includes llvm/MC/MCParser/MCAsmLexer.h

Preprocessed lines to build llvm on my setup:
after: 1068185081
before: 1068324320

So no compile time benefit to expect, but we still get the looser coupling
between files which is great.

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

show more ...

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

[MC] Add MCAsmParser::parseRParen to improve consistency and simplify code

Some diagnostics are more verbose but they don't seem to be more useful than
simple `expected ')'`

[llvm][ADT] Implement `BitVector::{pop_,}back`

LLVM Programmer’s Manual strongly discourages the use of `std::vector<bool>` and suggests `llvm::BitVector` as a possible replacement.

Currently, some

[llvm][ADT] Implement `BitVector::{pop_,}back`

LLVM Programmer’s Manual strongly discourages the use of `std::vector<bool>` and suggests `llvm::BitVector` as a possible replacement.

Currently, some users of `std::vector<bool>` cannot switch to `llvm::BitVector` because it doesn't implement the `pop_back()` and `back()` functions.

To enable easy transition of `std::vector<bool>` users, this patch implements `llvm::BitVector::pop_back()` and `llvm::BitVector::back()`.

Reviewed By: dexonsmith

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

show more ...

[llvm] Remove redundant member initialization (NFC)

Identified with readability-redundant-member-init.

Revert "[llvm] Remove redundant member initialization (NFC)"

This reverts commit fd4808887ee47f3ec8a030e9211169ef4fb094c3.

This patch causes gcc to issue a lot of warnings like:

warning: base cl

Revert "[llvm] Remove redundant member initialization (NFC)"

This reverts commit fd4808887ee47f3ec8a030e9211169ef4fb094c3.

This patch causes gcc to issue a lot of warnings like:

warning: base class ‘class llvm::MCParsedAsmOperand’ should be
explicitly initialized in the copy constructor [-Wextra]

show more ...

[llvm] Remove redundant member initialization (NFC)

Identified with readability-redundant-member-init.

[MC] Add Subtarget for MAsmParser call to emitCodeAlignment

The call to emitCodeAlignment was missing a STI which is required
after D45962.

emitCodeAlignment has a default parameter of 0 for MaxByt

[MC] Add Subtarget for MAsmParser call to emitCodeAlignment

The call to emitCodeAlignment was missing a STI which is required
after D45962.

emitCodeAlignment has a default parameter of 0 for MaxBytesToEmit.
Explicitly passing 0 here was interpreted as as nullptr for the STI.
This could possibly be avoided by taking STI as a const reference in
emitCodeAlignment.

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

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

[ms] [llvm-ml] Fix macro case-insensitivity

We previously had issues identifying macros not registered with a lowercase name.

Reviewed By: mstorsjo, thakis

Differential Revision: https://reviews.l

[ms] [llvm-ml] Fix macro case-insensitivity

We previously had issues identifying macros not registered with a lowercase name.

Reviewed By: mstorsjo, thakis

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

show more ...