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
