Stream: t-compiler/help

Topic: Inline asm


Amanieu (Jan 21 2020 at 21:19, on Zulip):

I'm starting the work on implementing the new asm! macro, but I'm not too familiar with the compiler internals.

Amanieu (Jan 21 2020 at 21:20, on Zulip):

In particular the new macro needs to do quite a bit of validation of the macro arguments, and I'm not sure where in the pipeline (AST/HIR/MIR) they would fit in.

Amanieu (Jan 21 2020 at 21:22, on Zulip):

Basically I need to:

Amanieu (Jan 21 2020 at 21:29, on Zulip):

For llvm_asm! it seems that almost all of the (fairly basic) validation is in librustc_builtin_macros, and LLVM catches any remaining errors in the backend.

Amanieu (Jan 21 2020 at 21:30, on Zulip):

But this won't work for my case since I need type information (among other things).

simulacrum (Jan 21 2020 at 21:30, on Zulip):

I think you should be able to do much of the validation in expansion (probably librustc_builtin_macros). The problematic bit will be the last two bullets (type information is not yet available).

However, I suspect that you can expand the macro to something like the existing InlineAsm thing and then type check in librustc_typeck

simulacrum (Jan 21 2020 at 21:31, on Zulip):

or you can also just stuff everything into a new exprkind and do the entire validation inside typeck, but that is probably worse (you'd want to stuff a lot of spans and so forth into the expr which would be not great)

Amanieu (Jan 21 2020 at 21:32, on Zulip):

My current plan is to rename the existing InlineAsm to LlvmInlineAsm and reimplement InlineAsm from scratch.

simulacrum (Jan 21 2020 at 21:33, on Zulip):

yes, that's what I would do

simulacrum (Jan 21 2020 at 21:33, on Zulip):

for the type checking you can look at how e.g. src/librustc_typeck/check/intrinsic.rs checks intrinsic types

Amanieu (Jan 21 2020 at 21:34, on Zulip):

Where's a good place to stuff the inline asm helper types & functions that are going to be used throughout all passes? libsyntax?

simulacrum (Jan 21 2020 at 21:35, on Zulip):

I would stick it in a separate helper crate

simulacrum (Jan 21 2020 at 21:35, on Zulip):

hm, unless I'm not following

simulacrum (Jan 21 2020 at 21:35, on Zulip):

what do you expect those types to contain?

Amanieu (Jan 21 2020 at 21:36, on Zulip):

Basically lists of every register & register class for every architecture, and a bitflags! for the asm flags.

simulacrum (Jan 21 2020 at 21:36, on Zulip):

ah

simulacrum (Jan 21 2020 at 21:36, on Zulip):

librustc_target, I guess, then

Amanieu (Jan 21 2020 at 21:36, on Zulip):

Sounds good.

Amanieu (Jan 21 2020 at 21:37, on Zulip):

I'll get started and pop back if I encounter any issues.

oli (Jan 21 2020 at 23:45, on Zulip):

Constant expression checking is only possible on MIR, you'll want to look at promote_consts and check out the logic for SIMD const args

simulacrum (Jan 21 2020 at 23:51, on Zulip):

hm, my impression was that constant expression meant a literal

simulacrum (Jan 21 2020 at 23:51, on Zulip):

(in which case the macro could directly parse it in)

simulacrum (Jan 21 2020 at 23:51, on Zulip):

but if that's wrong, then yeah

nagisa (Jan 22 2020 at 01:45, on Zulip):

hm, my impression was that constant expression meant a literal

foo(42) is also a "constant expression" by terminology accepted in rust (as long as foo is const fn)

nagisa (Jan 22 2020 at 01:45, on Zulip):

Anything that can be the initializer for const or static is a const expression.

nagisa (Jan 22 2020 at 01:46, on Zulip):

That being said, restricting accepted tokens in asm! imm would make sense too and be a conservative choice.

Christian Poveda (Jan 22 2020 at 02:54, on Zulip):

That being said, restricting accepted tokens in asm! imm would make sense too and be a conservative choice.

related? https://github.com/rust-lang/rust/issues/66556#issuecomment-555723836

Amanieu (Jan 22 2020 at 09:24, on Zulip):

Actually the plan is to support full constant expressions. For example I have a case where I want to pass the output of mem::size_of as an immediate operand.

Amanieu (Jan 22 2020 at 12:15, on Zulip):

Is the AST expected to match the source code exactly? If I preprocess the asm format string in librustc_builtin_macros then the AST pretty print will have a different asm string than the original.

Amanieu (Jan 22 2020 at 12:16, on Zulip):

I'm mainly talking about things like argument names:

asm!("mov {a}, {b}", a = out(reg) a, b = in(reg) b);
// becomes
asm!("mov {0}, {1}", out(reg) a, in(reg) b);
Amanieu (Jan 22 2020 at 12:24, on Zulip):

Also, how can I get the current target arch from librustc_builtin_macros? I need it to parse & validate the asm operands.

simulacrum (Jan 22 2020 at 14:18, on Zulip):

For the AST pretty printing differently, that's probably an artifact of pretty print... I would not rely on pretty print being accurate.

simulacrum (Jan 22 2020 at 14:27, on Zulip):

@Amanieu I think there's no way to get target information there just now, but you can thread it into ExtCtxt probably

Amanieu (Jan 22 2020 at 14:38, on Zulip):

Alternatively I could also defer validation until target information is available...

simulacrum (Jan 22 2020 at 14:38, on Zulip):

yeah, that might be easier

simulacrum (Jan 22 2020 at 14:39, on Zulip):

not sure

simulacrum (Jan 22 2020 at 14:39, on Zulip):

centralizing all validation until librustc_typeck could work

Amanieu (Jan 22 2020 at 14:59, on Zulip):

I'm looking at typeck and it doesn't feel like the right place for checking the types of asm operands.

Amanieu (Jan 22 2020 at 15:00, on Zulip):

It seems that typeck can only really express "must be this exact type" or "can be any type". What I need is "type must be one of [x, y, z...]".

Amanieu (Jan 22 2020 at 15:01, on Zulip):

I think this is better done in a later pass, while leaving the type inference as "can be any type".

simulacrum (Jan 22 2020 at 15:16, on Zulip):

hm, I would expect "must be one of [x, y, z,...]" to be a bunch of ors?

simulacrum (Jan 22 2020 at 15:16, on Zulip):

I don't see how that'll be different later on

simulacrum (Jan 22 2020 at 15:16, on Zulip):

I think you might be looking at the inference part of typeck

simulacrum (Jan 22 2020 at 15:17, on Zulip):

but there are non-inference parts too

Last update: Feb 25 2020 at 04:25UTC