This is an archive of the discontinued LLVM Phabricator instance.

[GlobalISel] Add extended inline assembler support
AbandonedPublic

Authored by kschwarz on Apr 6 2020, 3:08 AM.

Details

Summary

So far, GlobalISel only supports very basic inline assembler constructs (no input/output operands, only simple memory clobbers).

Thid patch adds support for generic register, immediate, memory and clobber constraints.
Before moving on with target specific operand constraints, I'd like to get some feedback on the general approach.
This patch will be accompanied by a corresponding RFC on the llvm-dev list.

Diff Detail

Event Timeline

kschwarz created this revision.Apr 6 2020, 3:08 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 6 2020, 3:08 AM
arsenm added inline comments.Apr 6 2020, 6:37 AM
llvm/lib/CodeGen/GlobalISel/IRTranslator.cpp
1634

Not sure why this is here, but it's weird to pass a MachineInstrBuilder to something

1647

s/unsigned/Register

1816

Don't need llvm::

1912

I think .isVirtual() should work here

1946

Need a newline here

1971

Needs newline

1973

Extra semicolon

1979

Missing newline

1986

Missing newline

1997

Missing newline

2027

Missing newline

2035

Missing newline

2122

Missing newline

llvm/lib/Target/AArch64/AArch64InstructionSelector.cpp
860

Construct this once at the start of the function?

861

I would expect you just need to constrain the vreg to the class and don't necessarily need a copy?

Is this just to feel out the general approach?

I think it would be a lot easier to give this a thorough review if it was split up into separate patches for each bit of inline assembly you're implementing.

Before moving on with target specific operand constraints, I'd like to get some feedback on the general approach.

In the past, I think we've been trying to keep target-specific stuff out of the IR Translator as much as possible. For example, CallLowering is its own thing.

Maybe it would make sense to take a similar approach to CallLowering here and split inline ASM lowering into its own thing, which targets can build upon?

(Also thanks for starting work on this!)

Is this just to feel out the general approach?

Yes, this is mostly to see how the logic would look like in GlobalISel land.

Maybe it would make sense to take a similar approach to CallLowering here and split inline ASM lowering into its own thing, which targets can build upon?

I posted this patch together with an RFC on llvm-dev (http://lists.llvm.org/pipermail/llvm-dev/2020-April/140661.html) where I would like to discuss exactly that approach.

Thanks to you both for having a look already!

Is this just to feel out the general approach?

Yes, this is mostly to see how the logic would look like in GlobalISel land.

Maybe it would make sense to take a similar approach to CallLowering here and split inline ASM lowering into its own thing, which targets can build upon?

I posted this patch together with an RFC on llvm-dev (http://lists.llvm.org/pipermail/llvm-dev/2020-April/140661.html) where I would like to discuss exactly that approach.

Thanks to you both for having a look already!

I've just replied to the RFC, but to re-iterate, I think having a generic lowering class for this code makes sense.

Can this be abandoned now that the separate class is committed?

kschwarz abandoned this revision.Jun 10 2020, 1:09 AM

Yes, abandoning this in favor of https://reviews.llvm.org/D78316