[cfe-dev] Why are the manglers in AST/ instead of CodeGen/ ?

[David Majnemer]

On Wed, Aug 28, 2013 at 11:13 PM, John McCall <rjmccall at apple.com> wrote:

> On Aug 28, 2013, at 9:56 PM, David Majnemer <david.majnemer at gmail.com>
> wrote:
> > A little backstory:
> >
> > I am working on improving the mangling non-type template arguments that
> bind pointers to members for the MS ABI and have hit on something rather
> unfortunate: mangling them is equivalent to mangling their offset in the
> record as a literal. The "obvious" thing to do would be to ask CodeGen what
> that constant offset would be, however that would be a layering violation
> because mangling happens in AST, not CodeGen.
>
> Record layout is performed on the AST, and offsets of struct members can
> easily be recovered there, modulo the -1 vs. 0 difference for null member
> pointers.
>
> > I'd like to know if the layer that mangling happens in is a consequence
> of design, or a philosophical choice or some other necessity.
>
> It was actually originally in IR-gen and got hoisted to AST because (1) it
> doesn’t rely on any “deep” IR-gen data structures and (2) people asked for
> it to be thusly hoisted.  I don’t see any reason to return it to IR-gen.
>
> > Answering this question would tell me if we could move mangling out or
> AST and into CodeGen or if I should instead move the member pointer layout
> calculation to MicrosoftCXXABI.cpp
>
> If you need proper member pointer layout in the AST, I have no issue with
> recording member pointer layout there.  Almost every reason that justifies
> struct layout being in the AST applies equally to member pointer layout, at
> least once you’ve settled that the MS dialect really is a separate universe
> from the language-as-standardized.
>
> John.


Thanks for the clarification! For the record, I need the real deal layout
as they produce manglings that are sensitive to vbtable/vftable
distinctions.

-- 
David Majnemer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130829/7bfce69c/attachment.html>