[PATCH] Microsoft C Record Layout

[Warren Hunt]

Another thing to note is that I'm about done with the C++ layout code which
I think I'm just going to add to this patch, which will about double the
code size and may alter this discussion some.  The overall approach is to
build something that is not dependent on the current implementation, make
sure it works, switch to it and then delete/clean all the existing code to
handle MS ABI in another patch.


On Fri, Jun 28, 2013 at 2:50 PM, Warren Hunt <whunt at google.com> wrote:

> That is reasonable, we can certainly fuse them into a single file and that
> will make sharing some C-layout code easier.  I can do that.  I personally
> find (more) smaller files easier to navigate and tend to break things
> apart.  Of course that causes either duplication of code or re-factoring
> into headers.
>
> -Warren
>
>
> On Thu, Jun 27, 2013 at 4:03 PM, John McCall <rjmccall at apple.com> wrote:
>
>> On Jun 27, 2013, at 1:16 PM, Warren Hunt <whunt at google.com> wrote:
>> > The C differences are, to my knowledge, only in bit-fields.  One of the
>> reasons that this C code has been broken into a separate file is because
>> I'm implementing C++ as an extension to the C code and it's going in the
>> same file.  The current state is that I should have a full MS-32-ABI C++
>> layout patch up late this week.  I presented a C patch first so that we
>> could start the code review process rather than some belief that compiling
>> C code in a MS-compatible way was particularly important.  The C++ patch
>> presently assumes the current structure where there's one file with C and
>> C++ semantics for MS.  It's been helpful for me to have all of the MS stuff
>> isolated so I can turn it off/on easily and gives me more confidence I'm
>> not breaking anything in the interim (it will also certainly make merging
>> with Eli's patch trivial).  I'm happy to have a discussion about the
>> ultimate organization of all of the layout code.  The MS C++ layout
>> algorithm is *completely different* than the Itanium one so I would suggest
>> keeping them separate.  Breaking C out from C++ can certainly be done and
>> may provide some benefit, presently my MicrosoftCXXRecordLayoutBuilder
>> inherits from the MicrosoftRecordLayoutBuilder.
>>
>> Sorry, I may not have been clear.  I'm not suggesting that you should put
>> the C code in the same file only to break it all out again when you do C++,
>> or to try to factor the C++ implementations to reuse things.  I'm
>> suggesting that, unless the correct Microsoft code is substantially larger
>> than the not-fully-correct code we've already got in
>> RecordLayoutBuilder.cpp, there may be advantages to just leaving all the
>> code in one file.  For example, it would make it easier to share what
>> common algorithms do exist between them (such as, presumably, the basic C
>> field layout algorithm, which will be shared among all the implementations,
>> but which is not totally trivial due to all the random things that adjust
>> field alignment) without needing to expose any of that.
>>
>> John.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130628/4f5f67f3/attachment.html>