[llvm-dev] DebugInfo: purpose of align field

Mon Oct 3 18:39:04 PDT 2016

> On Oct 3, 2016, at 2:27 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Mon, Oct 3, 2016 at 2:24 PM Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 
> > On Sep 30, 2016, at 4:05 PM, Victor Leschuk <vleschuk at accesssoftek.com <mailto:vleschuk at accesssoftek.com>> wrote:
> >
> > Hello Adrian, sorry for the delay with the response. Somehow I missed your message..
> >
> > On 09/13/2016 12:43 AM, Adrian Prantl wrote:
> >>> On Sep 10, 2016, at 12:50 PM, Victor Leschuk via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> >>>
> >>> Hello all,
> >>>
> >>> I am currently implementing support for DWARFv5 DW_AT_alignment attr and I got a question about align field in debug info section of IR/Bitcode.
> >> Thanks for looking into this!
> > No problem =)
> >>
> >>> Currently it is being dumped almost in any case, however according to code we use align from DI* objects only when dealing with class/structure bitfields: DwarfUnit::constructMemberDIE.
> >>>
> >>> Dumping align information everywhere only for 1 case looks like overhead to me.
> >> One your patch is finished it will be used in more cases, right? :-)
> > My point is that we dump align information everywhere and it is currently used only in 1 case. I am trying to make it so that it is dumped only when it is necessary.
> >>> Consider the following code:
> >>>
> >>> struct S {
> >>>  char c;
> >>> } s;
> >>>
> >>> When compiled with debug enabled in IR we get smth like that:
> >>>
> >>> !6 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "S", file: !5, line: 1, size: 8, align: 8, elements: !7)
> >>>
> >>> Am I missing something? What is the purpose of "align: 8" here? Maybe we could include alignment information into DI* objects only when required (and thus dump it only when required): for types with bitfields and when alignas() was specified in code.
> >> What do you mean by "include" in this context? Are you arguing for making an alignment of 8 the implicit default in textual IR? Or do you want to make DICompositeType variable length?
> > I mean that in this case alignment isn't used anywhere in code further. I think we don't need alignment information in textual DI IR in case it is not default. Dumping default alignment in every case doesn't make sense for me: if we dump align info each time we need to mark "special" cases with additional flag in order to be able to know which case to "report" in DWARF. If we dump only "forced" alignment, we can just say: "Ok, alignment is specified, we need to put this into DWARF".
> 
> I'm not sure I understand your point.
> 
> In textual IR (lib/IR/AsmWriter.cpp & friends) we generally don't care too much about how verbose the output is, since this representation is primarily used for debugging.
> 
> From how you phrased your reply it is also possible that you were instead thinking about the in-memory representation? Currently every DIType (include/IR/DebugInfoMetadata.h) uses a unit64_t field to store the alignment.
> 
> IIUC, your goal is to avoid emitting a DW_AT_alignment attribute to types that use the default alignment. Would it make sense to store the target's default alignment in the DIType::AlignInBits field, so the DWARF backend can then decide not emit the DW_AT_alignment when it sees it?
> 
> This whole thread's got a bit long/confusing for me, but some of what's going on might be suggestions I made earlier. My rough idea is that:
> 
> 1) We should probably only put alignment on metadata nodes that we want the DW_AT_alignment attribute to be generated for (keeps the model simple) - leave it zero otherwise.

My thought was that we're not saving any space by storing zero so might as well just store the actual alignment there, it might help with debugging or be otherwise useful. But — I don't have a particular use-case in mind. If storing zero makes the model simpler, we can do that as well, either way is fine. Does COFF perhaps need the alignment?

> 2) It'd be nice not to print the zero, to keep the textual representation simple/less noisy (as we do with many other metadata fields)

I'm fine with not printing zero (Victor: ideally, this be a separate commit). I'm not so comfortable with not not printing any other values (such as 8).

thanks for the explanation,
adrian
> 
> But it's not a big deal if someone else feels strongly.
> 
> - Dave
>  
> 
> -- adrian
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <http://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/20161003/f11fb22e/attachment.html>