Qing already answered this question long ago:
The alignment is correct in .B file, but in Adjusted_Alignment there
are following code to modify the align. In our case we do not want
this happen.
else {
align = MAX(align, Aggregate_Alignment);
}
Align_aggregate=8 will set the value of Aggregate_Alignment to 8. "align" is
also 8 in this case.
在 2011年8月25日 下午9:46，Sun Chan <sun.c...@gmail.com>写道：
> All these are valid to me. I have another question for Zqing. Why does
> Align_aggregate=8 work? What is changed?
> Sun
>
> 2011/8/25 Stephen Clarke <stephen.cla...@st.com>:
> > I really don't have strong opinions on this issue, but it is
> > something that I have needed to think about from time to
> > time for our target, so I can at least give my thoughts.
> > Disclaimer: this is just based on working with the code and
> > documentation, I don't have any particular insights, and I may
> > well misinterpret something.
> >
> > My understanding of the align information in the ty_idx
> > is that it is, initially, a "summary" of the required alignment,
> > given the alignment requirements of the ABI, the type,
> > and the decl (including any gnu attributes). For the
> > output of the frontend, this is the "intended alignment".
> >
> > After the frontend, an optimization phase should be allowed
> > to change the alignment of objects, for code improvement
> > purposes, where such a change is legal. (By "legal" I mean,
> > it doesn't break the language semantics, or the ABI.)
> > And in the implementation this is done by rewriting the align
> > information in the ty_idx.
> >
> > But now it's necessary to support a gcc attribute which forbids
> > optimizing the alignment of an object. It's a new
> > "language semantics" rule that the alignment optimizer needs
> > to follow. Somehow, the alignment optimizer needs to know
> > when this rule applies to an object.
> >
> > What I don't have a very strong idea of, is how to consider
> > the Aggregate_Alignment variable, which is treated by
> > Adjusted_Alignment(). I think of it as an optimization, i.e.
> > it doesn't change language or ABI rules, so Adjusted_Alignment()
> > is just like an optimization phase performing an alignment
> > optimization.
> >
> > Rgds,
> > Steve.
> >
> > Sun Chan wrote:
> >> you are always welcome to give opinion, why not!
> >> I am forgetting a lot of the details, why can't the bit in ty_idx to
> >> specify the "intended" alignment? If one can specify a larger
> >> alignment, the reverse is possible too, right? When we did the
> >> alignment bit, I don't believe we were thinking of just increasing
> >> alignment.
> >> Sun
> >>
> >> 2011/8/25 Stephen Clarke <stephen.cla...@st.com>:
> >>> Ok. I deliberately avoided giving an opinion on where
> >>> the "user aligned" information should be stored.
> >>>
> >>> But I can think of three possibilities:
> >>> 1. A flag in the ST (i.e. the proposal).
> >>> 2. A bit in the TY_IDX (the same place as the align).
> >>> 3. A flag in the TY.
> >>>
> >>> For #2, there is some issue that it is a fixed 32-bit
> >>> entity, and there are no free bits. So a bit needs to be stolen,
> >>> either from the (currently 24-bit) index into the type table,
> >>> or else from the (currently 5-bit) alignment value.
> >>> I worry about stealing a bit from the alignment, leaving only
> >>> 4 bits, so I suppose it would have to come from the index field.
> >>>
> >>> Rgds,
> >>> Steve.
> >>>
> >>> Sun Chan wrote:
> >>>> I am not disputing that. I am objecting to two ways (and in diff
> >>>> places) to handle that
> >>>>
> >>>> 2011/8/25 Stephen Clarke <stephen.cla...@st.com>:
> >>>>> Gcc behaviour for attribute aligned has changed a little in the
> >>>>> last few years. Previously it used to state:
> >>>>>
> >>>>> "The `aligned' attribute can only increase the alignment; but you
> >>>>> can decrease it by specifying `packed' as well."
> >>>>>
> >>>>> and so it used to be okay for Adjust_Alignment to always
> >>>>> increase the alignment.
> >>>>>
> >>>>> But in most gcc recent versions, it allows for attribute aligned
> >>>>> to decrease alignment also, and so to match gcc behaviour,
> >>>>> Adjust_Alignment ought not to increase the alignment in that case.
> >>>>> So there needs to be some way to detect the case. The proposal is
> >>>>> to handle that by adding a boolean flag indicating that the
> >>>>> alignment was user-specified.
> >>>>>
> >>>>> (Ok, I'm just repeating what Jian-Xin Lai has already said... but
> >>>>> with some explanation for why there used not to be a problem here.)
> >>>>>
> >>>>> Rgds,
> >>>>> Steve.
> >>>>>
> >>>>> Sun Chan wrote:
> >>>>>> the point is, I don't think you need two places to store alignment
> >>>>>> info, user specified or not
> >>>>>> Sun
> >>>>>>
> >>>>>> 2011/8/25 Jian-Xin Lai <laij...@gmail.com>:
> >>>>>>> No, there is no case with 2 different alignment. ST's alignment is
> saved in
> >>>>>>> ST's TY_IDX, not in the TY. The front end will set the correct
> alignment for
> >>>>>>> the ST for all cases. TY only keeps the size of the type. TY doen't
> have the
> >>>>>>> alignment size.
> >>>>>>>
> >>>>>>> 在 2011年8月25日 下午4:19，Sun Chan <sun.c...@gmail.com>写道：
> >>>>>>>> it's not a question. I am saying, symbol of different alignment
> should
> >>>>>>>> have different type. Hence, the alignment is associated at type
> table,
> >>>>>>>> not symtab
> >>>>>>>> Sim
> >>>>>>>>
> >>>>>>>> 2011/8/25 Jian-Xin Lai <laij...@gmail.com>:
> >>>>>>>>> I'm not sure if I understand your question. The TY_IDX is
> composed by 2
> >>>>>>>>> parts: index to TY_TABLE and extra flags for volatile, restrict
> and
> >>>>>>>>> alignment. Every symbol with the same TY has its own alignment
> embeded
> >>>>>>>>> in
> >>>>>>>>> the TY_IDX.
> >>>>>>>>>
> >>>>>>>>> 在 2011年8月25日 下午4:01，Sun Chan <sun.c...@gmail.com>写道：
> >>>>>>>>>> I have problem having one attribute that have annotation in 2
> >>>>>>>>>> different places. Also, the reason it is in TYPE is that symbols
> of
> >>>>>>>>>> the same declaration but of different alignment should really be
> of
> >>>>>>>>>> different type.
> >>>>>>>>>> Sun
> >>>>>>>>>>
> >>>>>>>>>> 2011/8/25 Jian-Xin Lai <laij...@gmail.com>:
> >>>>>>>>>>> The TY has "packed" flag and it's detected in Adjust_Alignment:
> >>>>>>>>>>> 125 align= TY_align(ty_idx);
> >>>>>>>>>>> 126
> >>>>>>>>>>> 127 if (Is_Structure_Type(ty) && TY_is_packed(ty))
> >>>>>>>>>>> 128 {
> >>>>>>>>>>> 129 return align;
> >>>>>>>>>>> 130 }
> >>>>>>>>>>>
> >>>>>>>>>>> If the TY is packed, the BE don't change its alignment. We did
> the
> >>>>>>>>>>> similar
> >>>>>>>>>>> thing. The different is our change is applied on ST instead of
> TY
> >>>>>>>>>>> because
> >>>>>>>>>>> this is a GNU extension on variable.
> >>>>>>>>>>>
> >>>>>>>>>>> 在 2011年8月25日 下午3:05，Sun Chan <sun.c...@gmail.com>写道：
> >>>>>>>>>>>> How would you classify "pack" data?
> >>>>>>>>>>>> Sun
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2011/8/25 Jian-Xin Lai <laij...@gmail.com>:
> >>>>>>>>>>>>> The reason we introduce the "user align" is to separate this
> kind
> >>>>>>>>>>>>> of
> >>>>>>>>>>>>> case
> >>>>>>>>>>>>> from the generic aggregate. So that we can do the two things
> well:
> >>>>>>>>>>>>> If user specifies an alignment, we follow the size.
> Otherwise, the
> >>>>>>>>>>>>> compiler
> >>>>>>>>>>>>> can decide what's the proper alignment.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 在 2011年8月25日 下午1:57，Mike Murphy <mmur...@nvidia.com>写道：
> >>>>>>>>>>>>>> So Aggregate_Alignment is a settable option (defaults to 16
> in
> >>>>>>>>>>>>>> some
> >>>>>>>>>>>>>> targets). What if you compile with
> -TENV:align_aggregates=8, or
> >>>>>>>>>>>>>> don't
> >>>>>>>>>>>>>> default it to 16?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>> From: 朱庆 [mailto:zqing1...@gmail.com]
> >>>>>>>>>>>>>> Sent: Wednesday, August 24, 2011 10:53 PM
> >>>>>>>>>>>>>> To: Mike Murphy
> >>>>>>>>>>>>>> Cc: Sun Chan; open64-devel@lists.sourceforge.net
> >>>>>>>>>>>>>> Subject: Re: [Open64-devel] Code Review request for
> bug832[wgen]
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The alignment is correct in .B file, but in
> Adjusted_Alignment
> >>>>>>>>>>>>>> there
> >>>>>>>>>>>>>> are following code to modify the align. In our case we do
> not
> >>>>>>>>>>>>>> want
> >>>>>>>>>>>>>> this happen.
> >>>>>>>>>>>>>> else {
> >>>>>>>>>>>>>> align = MAX(align, Aggregate_Alignment);
> >>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Best wishes
> >>>>>>>>>>>>>> zhuqing
> >>>>>>>>>>>>>> 在 2011年8月25日 下午12:28，Mike Murphy <mmur...@nvidia.com> 写道：
> >>>>>>>>>>>>>>> The alignment is stored in the ty_idx (see TY_align), and
> then
> >>>>>>>>>>>>>>> there
> >>>>>>>>>>>>>>> are
> >>>>>>>>>>>>>>> routines like Adjusted_Alignment in stblock that can modify
> it.
> >>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>> suspect
> >>>>>>>>>>>>>>> the problem here is that the alignment is being put on the
> >>>>>>>>>>>>>>> object
> >>>>>>>>>>>>>>> rather
> >>>>>>>>>>>>>>> than the type, and then is lost (but should still be
> possible,
> >>>>>>>>>>>>>>> because the
> >>>>>>>>>>>>>>> TY_align is like qualifiers that can vary from the base
> type).
> >>>>>>>>>>>>>>> Does
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>> alignment show up properly in the intermediate .B file?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>> From: Sun Chan [mailto:sun.c...@gmail.com]
> >>>>>>>>>>>>>>> Sent: Wednesday, August 24, 2011 7:51 PM
> >>>>>>>>>>>>>>> To: 朱庆
> >>>>>>>>>>>>>>> Cc: open64-devel@lists.sourceforge.net
> >>>>>>>>>>>>>>> Subject: Re: [Open64-devel] Code Review request for
> >>>>>>>>>>>>>>> bug832[wgen]
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The reason I asked for the file is that I think there has
> to be
> >>>>>>>>>>>>>>> some
> >>>>>>>>>>>>>>> alignment attribute somewhere. I am sure data alignment has
> >>>>>>>>>>>>>>> been
> >>>>>>>>>>>>>>> dealt
> >>>>>>>>>>>>>>> with in the compiler. That it is due to user, or just
> language
> >>>>>>>>>>>>>>> attribute might be irrelevant from compiler point of view.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Mike or Murthy,
> >>>>>>>>>>>>>>> Do you remember where alignment is handled? I only found
> >>>>>>>>>>>>>>> Alignment
> >>>>>>>>>>>>>>> field in BLK of the symtab_defs.h
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Sun
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> 2011/8/25 朱庆 <zqing1...@gmail.com>:
> >>>>>>>>>>>>>>>> Hi Sun,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Attached symtab_defs.h.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thanks
> >>>>>>>>>>>>>>>> zhuqing
> >>>>>>>>>>>>>>>> 2011/8/24 Sun Chan <sun.c...@gmail.com>:
> >>>>>>>>>>>>>>>>> can you send me the full symtab_defs.h?
> >>>>>>>>>>>>>>>>> Sun
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Wed, Aug 24, 2011 at 4:56 PM, 朱庆 <zqing1...@gmail.com
> >
> >>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Can gatekeeper help review following fix for bug832?
> >>>>>>>>>>>>>>>>>> https://bugs.open64.net/show_bug.cgi?id=832
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> small case, a.c:
> >>>>>>>>>>>>>>>>>> struct obs_kernel_param {
> >>>>>>>>>>>>>>>>>> const char *str;
> >>>>>>>>>>>>>>>>>> };
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> const char str1[] = "acpi_parse_apic_instance=";
> >>>>>>>>>>>>>>>>>> const char str2[] = "acpi_os_name";
> >>>>>>>>>>>>>>>>>> struct obs_kernel_param var1
> >>>>>>>>>>>>>>>>>> __attribute__ ((aligned ((sizeof (long))))) =
> >>>>>>>>>>>>>>>>>> {str1};
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> struct obs_kernel_param var2
> >>>>>>>>>>>>>>>>>> __attribute__ ((aligned ((sizeof (long))))) =
> >>>>>>>>>>>>>>>>>> {str2};
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> when compile with opencc, nm a.o
> >>>>>>>>>>>>>>>>>> 0000000000000000 D var1
> >>>>>>>>>>>>>>>>>> 0000000000000010 D var2
> >>>>>>>>>>>>>>>>>> compile with gcc, nm a.o
> >>>>>>>>>>>>>>>>>> 0000000000000000 D var1
> >>>>>>>>>>>>>>>>>> 0000000000000008 D var2
> >>>>>>>>>>>>>>>>>> the offset of var1 and var2 are different, the problem
> with
> >>>>>>>>>>>>>>>>>> opencc
> >>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>> :fixed align attribute does not work, this may cause
> some
> >>>>>>>>>>>>>>>>>> problems
> >>>>>>>>>>>>>>>>>> when mix link two files with opencc and gcc.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The fix is to add a new ST flag to record
> >>>>>>>>>>>>>>>>>> user_defined_align.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Thanks
> >>>>>>>>>>>>>>>>>> zhuqing
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> ------------------------------------------------------------------------------
> >>>>>>>>>>>>>>>>>> EMC VNX: the world's simplest storage, starting under
> $10K
> >>>>>>>>>>>>>>>>>> The only unified storage solution that offers unified
> >>>>>>>>>>>>>>>>>> management
> >>>>>>>>>>>>>>>>>> Up to 160% more powerful than alternatives and 25% more
> >>>>>>>>>>>>>>>>>> efficient.
> >>>>>>>>>>>>>>>>>> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> >>>>>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>>>>> Open64-devel mailing list
> >>>>>>>>>>>>>>>>>> Open64-devel@lists.sourceforge.net
> >>>>>>>>>>>>>>>>>>
> https://lists.sourceforge.net/lists/listinfo/open64-devel
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> ------------------------------------------------------------------------------
> >>>>>>>>>>>>>>> EMC VNX: the world's simplest storage, starting under $10K
> >>>>>>>>>>>>>>> The only unified storage solution that offers unified
> >>>>>>>>>>>>>>> management
> >>>>>>>>>>>>>>> Up to 160% more powerful than alternatives and 25% more
> >>>>>>>>>>>>>>> efficient.
> >>>>>>>>>>>>>>> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> >>>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>>> Open64-devel mailing list
> >>>>>>>>>>>>>>> Open64-devel@lists.sourceforge.net
> >>>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/open64-devel
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> -----------------------------------------------------------------------------------
> >>>>>>>>>>>>>>> This email message is for the sole use of the intended
> >>>>>>>>>>>>>>> recipient(s)
> >>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>> may contain
> >>>>>>>>>>>>>>> confidential information. Any unauthorized review, use,
> >>>>>>>>>>>>>>> disclosure
> >>>>>>>>>>>>>>> or
> >>>>>>>>>>>>>>> distribution
> >>>>>>>>>>>>>>> is prohibited. If you are not the intended recipient,
> please
> >>>>>>>>>>>>>>> contact
> >>>>>>>>>>>>>>> the sender by
> >>>>>>>>>>>>>>> reply email and destroy all copies of the original message.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> -----------------------------------------------------------------------------------
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> ------------------------------------------------------------------------------
> >>>>>>>>>>>>>> EMC VNX: the world's simplest storage, starting under $10K
> >>>>>>>>>>>>>> The only unified storage solution that offers unified
> management
> >>>>>>>>>>>>>> Up to 160% more powerful than alternatives and 25% more
> >>>>>>>>>>>>>> efficient.
> >>>>>>>>>>>>>> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> >>>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>>> Open64-devel mailing list
> >>>>>>>>>>>>>> Open64-devel@lists.sourceforge.net
> >>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/open64-devel
> >>>>>>>>>>>>> --
> >>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>> Lai Jian-Xin
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> ------------------------------------------------------------------------------
> >>>>>>>>>>>>> EMC VNX: the world's simplest storage, starting under $10K
> >>>>>>>>>>>>> The only unified storage solution that offers unified
> management
> >>>>>>>>>>>>> Up to 160% more powerful than alternatives and 25% more
> efficient.
> >>>>>>>>>>>>> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> >>>>>>>>>>>>> _______________________________________________
> >>>>>>>>>>>>> Open64-devel mailing list
> >>>>>>>>>>>>> Open64-devel@lists.sourceforge.net
> >>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/open64-devel
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>>> Regards,
> >>>>>>>>>>> Lai Jian-Xin
> >>>>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Regards,
> >>>>>>>>> Lai Jian-Xin
> >>>>>>>>>
> >>>>>>> --
> >>>>>>> Regards,
> >>>>>>> Lai Jian-Xin
> >>>>>>>
> >>>>>>
> ------------------------------------------------------------------------------
> >>>>>> EMC VNX: the world's simplest storage, starting under $10K
> >>>>>> The only unified storage solution that offers unified management
> >>>>>> Up to 160% more powerful than alternatives and 25% more efficient.
> >>>>>> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> >>>>>> _______________________________________________
> >>>>>> Open64-devel mailing list
> >>>>>> Open64-devel@lists.sourceforge.net
> >>>>>> https://lists.sourceforge.net/lists/listinfo/open64-devel
> >>>
> >
> >
>
--
Regards,
Lai Jian-Xin
------------------------------------------------------------------------------
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management
Up to 160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
