[llvm-dev] [GlobalISel] Extended inline assembler support

Amara Emerson via llvm-dev llvm-dev at lists.llvm.org
Mon Apr 6 17:34:30 PDT 2020

Hi Konstantin,

> On Apr 6, 2020, at 3:11 AM, Konstantin Schwarz via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> Hi!
> So far, GlobalISel only supports very basic inline assembler constructs (no input/output operands, only simple memory clobbers).
> In [0], I'm adding support for generic register, immediate, memory and clobber constraints.
> The code is more or less a direct port from the handling in SelectionDAGBuilder.
Awesome, thanks!
> Before moving on with target specific constraints, I'd like to discuss the general strategy for target hooks in GlobalISel.
> While most of these hooks on the SelectionDAG side live in the TargetLowering class, there is no corresponding GlobalISel subclass of the TargetLoweringBase class yet.
> Instead, the (one) existing GlobalISel hook currently lives in TargetLoweringBase.
> For lowering the target specific constraints, we'll have to add a new API that creates (G)MIR during IR translation.
> Personally I would prefer to have an InlineAsmLowering class, similar to the CallLowering class, which implements the generic algorithm and from which targets can inherit.
> Most of the implementation in [0] could then be moved to that class.
> However, this would add yet another class that needs to be wired up in the subtarget class. Is this something we would like to avoid?
> Is there a better place where target specific GlobalISel hooks should be added?
I don’t think it’s a problem to have another lowering base class for GlobalISel. IMO it’s not much overhead to inherit and override an existing class versus having one monolithic lowering class. In terms of organization, there’s nothing stopping targets from having all of their XYZLowering extensions in a single file, much like TargetLowering today. If there’s some code re-use that’s possible between these various lowering classes then that’s a different story.

> Thanks for your feedback!
> Best regards,
> Konstantin
> [0] https://reviews.llvm.org/D77535
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

More information about the llvm-dev mailing list