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
>>>
>
>
------------------------------------------------------------------------------
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
