Support using const pointers in asm const operand

[nbdd0121]

Implements RFC#3848 with tracking issue #128464

This adds support of const pointers for asm const in addition to plain integers.

The inline asm! support is implemented using i constraint, and the global_asm! and naked_asm! support is implemented by inserting symbol + offset and make symbol compiler-used. For unnamed consts, it will create additional internal & hidden symbols so that they can be referenced by global_asm.

The feature is also implemented for GCC backend but it's untested.

[rustbot]

r? @fmease

rustbot has assigned @fmease.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[fmease]

r? codegen

[compiler-errors]

r? compiler-errors

[rustbot]

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[compiler-errors]

Please add more doc comment explaining the significance of the difference between Interpolate and Const for backends. It begs the question for why we ever turn const operands into strings, for example.

[nbdd0121]

Added some explaination. Technically we should be able to use Const for integers, although I am a bit conservative here and don't want to change how existing things work.

This might also be useful to have in the future if we decided to add interpolate "some CTFE string to be interpolated" new type of operand.

[bors]

☔ The latest upstream changes (presumably #140415) made this pull request unmergeable. Please resolve the merge conflicts.

[traviscross]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[bors]

☔ The latest upstream changes (presumably #141668) made this pull request unmergeable. Please resolve the merge conflicts.

[workingjubilee]

// x86_64: mov al, byte ptr [{{.*}}anon{{.*}}]

What was the expansion you observed?

[nbdd0121]

mov al, byte ptr [.Lanon.2e8c0013b01edcd3779e8174c2338a00.0]

[bors]

☔ The latest upstream changes (presumably #144249) made this pull request unmergeable. Please resolve the merge conflicts.

[Darksonn]

Looks like the i constraint doesn't work for GOT-rebased relocation

I've been playing around with this a bit, and I think the i operand works as long as using the symbol name would work. For example, this breaks:

#include <stdio.h>

static const int FORTY_TWO = 42;

int main(void) {
    const int *a;

    __asm__ (
        "movabs %1, %0"
        : "=r" (a)
	: "i" (&FORTY_TWO)
    );

    printf("%p\n", (void *)a);

    return 0;
}

/usr/bin/ld: /tmp/ccptrDbi.o: warning: relocation in read-only section `.text'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE

But when we make it rip-relative, it works:

#include <stdio.h>

static const int FORTY_TWO = 42;

int main(void) {
    const int *a;

    __asm__ (
        "movabs %1 - ., %0"
        : "=r" (a)
	: "i" (&FORTY_TWO)
    );

    printf("%p\n", (void *)a);

    return 0;
}

0xec3

We can even force it to generate a GOT-entry with the address of FORTY_TWO and then look up the value through it:

#include <stdio.h>

static const int FORTY_TWO = 42;

int main(void) {
    const int **a;

    __asm__ (
        "leaq (%c1)@GOTPCREL(%%rip), %0"
        : "=r" (a)
	: "i" (&FORTY_TWO)
    );

    printf("%i\n", **a);

    return 0;
}

42

This is exactly the same scenario as when writing FORTY_TWO would work as far as I can tell. Is there something I'm missing?

[nbdd0121]

It works in x64 but not in x86.

EDIT: Looks like it works in GCC for not Clang/LLVM: https://godbolt.org/z/YodbxxMeY

[Darksonn]

Ah, that's what I get for testing it with gcc.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Darksonn]

What about negative offset? Should it be symbol-offset instead of the current symbol+-offset?

[nbdd0121]

Hmm, offset is unsigned, so I elected to just emit +{offset}. If the offset is negative, CTFE will just produce 2's complement values as unsigned (which is okay for the wrapping semantics, and note that you have to use wrapping semantics to get pointer out of bound in the first place).

Assemblers seem to be happy with +0xFFFFFFFFFFFFFFFF instead of -1; do you think it's worth changing the generated code so we always treat offset as signed?

[Darksonn]

IMO -1 seems a lot safer than +0xFFFFFFFFFFFFFFFF since we don't have to worry about the bitwidth of the addition.

[nbdd0121]

Quite a few changes for this new version:

• i operand isn't used anymore, due to the i686 limitation discussed above. The code is updated to always generate {symbol}{offset:+} instead (when symbol is still either interpolated directly or inserted by backend, depending on backend's capability of doing so).
• sym fn and const pointers are now unified, as this new approach produces identical assembly for const f and sym f.
• sym static is not unified. sym STATIC and const &STATIC are mostly the same, but sym works for #[thread_local] statics, while reference to #[thread_local] statics cannot be taken in CTFE.
• Commits are broken down into smaller (yet individually still meaningful pieces for help commit-by-commit review).