This is an archive of the discontinued LLVM Phabricator instance.

Print target inline asm memory constraints
AcceptedPublic

Authored by borisboesler on Dec 2 2021, 7:01 AM.

Details

Summary

In LLVM target dependent inline asm constraints can be defined - for registers and memories. But if MachineInstrs are printed, LLVM fails in InlineAsm::getMemConstraintName() to print target inline asm memory constraints.
With this patch memory constraints can be defined starting at InlineAsm::Constraints_Max + 1 and can be printed by overwriting virtual method TargetInstrInfo::getInlineAsmMemConstraintName.

Diff Detail

Event Timeline

borisboesler created this revision.Dec 2 2021, 7:01 AM
borisboesler requested review of this revision.Dec 2 2021, 7:01 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 2 2021, 7:01 AM

Change to follow lint rules

kschwarz added inline comments.Dec 14 2021, 6:05 AM
llvm/include/llvm/IR/InlineAsm.h
266

As far as I understand, upstream targets define their (target) specific memory constraints in this common enum.
The Constraints_Max value is used in the assertion to make sure all upstream constraints are handled properly.

Why do you need to remove the assertion upstream? I would rather expect your downstream target to add more values to this enum, and to handle them in getMemConstraintName.

borisboesler added inline comments.Dec 14 2021, 7:15 AM
llvm/include/llvm/IR/InlineAsm.h
266

Why should we add target related things in llvm/IR? We do not add target opcodes in llvm/IR/ISDOpcodes.h. I propose to keep target related code in their target codebase.

dsanders accepted this revision.Jan 4 2022, 4:00 PM
dsanders added inline comments.
llvm/include/llvm/IR/InlineAsm.h
266

As far as I understand, upstream targets define their (target) specific memory constraints in this common enum.

That's true at the moment but as far as I can remember there was no particularly good reason for it to be here rather than in the target (for example, AFAICT the numbers aren't used in the bitcode format). There just wasn't anything justifying the extra plumbing.

For in-tree targets there isn't really a practical reason to move it to the target but I agree it belongs there in principle. For out-of-tree targets there's some small but nice befits for both merge pain and binary compatibility (e.g. a shared library adding a new target to an existing LLVM)

LGTM

This revision is now accepted and ready to land.Jan 4 2022, 4:00 PM
borisboesler marked an inline comment as not done.Jan 18 2022, 1:34 AM
borisboesler added inline comments.
llvm/include/llvm/IR/InlineAsm.h
266

As far as I understand, upstream targets define their (target) specific memory constraints in this common enum.

That's true at the moment but as far as I can remember there was no particularly good reason for it to be here rather than in the target (for example, AFAICT the numbers aren't used in the bitcode format). There just wasn't anything justifying the extra plumbing.

For in-tree targets there isn't really a practical reason to move it to the target but I agree it belongs there in principle. For out-of-tree targets there's some small but nice befits for both merge pain and binary compatibility (e.g. a shared library adding a new target to an existing LLVM)

LGTM

Thanks. I don't have commit access. Could you commit it for me, please?