[llvm-dev] [MCAssembler] changing layout in assembler backend

[James Y Knight via llvm-dev]

I don't really know the history, but I was just looking at this and
wondering if I could rip out that entire infrastructure since it seems to
be rather complex dead-code.

There's an abandoned follow-on patch https://reviews.llvm.org/D34396 that
may be helpful to look at.

On Fri, Nov 22, 2019 at 11:52 AM Davis, Alan via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> … Replying to my own message since no one else did :-;
>
>
>
> … and hoping for a little insight on the MCCodePadding class.
>
>
>
> Essentially I need a way to create alignment padding whose size can be
> adjusted based on the content (not just the address) of other MCFragments.
> (MCAlignFragments don’t quite fit the bill because they only look at the
> next Fragment’s Offset, not its contents.) It seems like this sort of
> aligns with the purpose of MCCodePadder, which adjusts the size of an
> MCPaddingFragment based on other fragments. But MCCodePadder is an enigma.
> No targets seem to use it; it has virtual methods as if it’s intended for
> targets to override it MCAssembler is hardwired to construct the base
> class; its addPolicy() is also protected from target access; and it’s not
> clear what it’s actually intending to do – in particular I don’t get the
> “window” concept.
>
>
>
> Can anyone shed light on how this is supposed to work?
>
>
>
> -Alan
>
>
>
> *From:* Davis, Alan
> *Sent:* Wednesday, November 20, 2019 5:07 PM
> *To:* LLVM Developers Mailing List
> *Subject:* [MCAssembler] changing layout in assembler backend
>
>
>
> Our target has a perhaps unique problem relating to code alignment. Like
> other targets, it wants to insert NOPs for an FT_Align fragment. The unique
> part is that it has a way to “fold” these NOPs into the previous
> instruction packet, so that when falling through to the aligned label there
> is no execution penalty. Doing so requires re-encoding the previous packet,
> which “enlarges” it such that no actual NOPs are needed.
>
>
>
> So I’d like to do this in the target-specific MCAsmBackend, in the
> finishLayout hook which is called after the MCAssembler finishes the layout
> pass. The idea is to look for FT_Align fragments, see how much padding they
> generate, find the previous packet, and re-encode it. The problem is that
> doing so changes the layout – sort of. Actually, it just changes the offset
> of the FT_Align fragment because the previous packet is larger. I could
> just do that directly… but the Offset member is private to the Fragment and
> only settable by its friend the MCAsmLayout class.
>
>
>
> I looked at doing this via relaxation but there is not enough context. In
> particular the backend’s relaxation API does not have access to the
> fragment list.
>
>
>
> Also I noticed there is an interesting looking mechanism called
> MCCodePadder, but it’s super obtuse and no in-tree targets seem to use it.
>
>
>
> For now I just made MCFragment’s Offset public and modified it directly
> from finishLayout. But that seems like it significantly undermines the
> design. Ideally I think the MCAsmBackend should have authority to do
> whatever it needs to do, including adjusting the layout (especially in an
> API called “finishLayout”) but currently that is not the case. I’m looking
> for advice on how to make this work with minimal changes to the existing
> APIs.
>
>
>
> -Alan
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191122/0279e9e7/attachment.html>