This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Variable DECL_SIZE


On Fri, Oct 5, 2012 at 2:36 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
> 2012/10/5 Richard Guenther <richard.guenther@gmail.com>:
>> On Fri, Oct 5, 2012 at 10:28 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>>> 2012/10/4 Richard Guenther <richard.guenther@gmail.com>:
>>>> On Wed, Oct 3, 2012 at 7:05 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> I fall into ssa verification failure when try to pass field's
>>>>> DECL_SIZE as an operand for CALL_EXPR. The fail occurs if field's size
>>>>> is not a constant. In such case DECL_SIZE holds a VAR_DECL and I need
>>>>> to find it's proper SSA_NAME. I thought it may be the default one but
>>>>> gimple_default_def returns NULL. What is the right way to obtain
>>>>> correct ssa_name in such case?
>>>>
>>>> There is no way.  You have to know that you need it's size at the point of
>>>> gimplification.  Later there is no way to recover it.
>>>
>>> Wow. It means I cannot also get an address of subsequent fields in the
>>> structure. It looks weird. Is there a way to somehow preserve this
>>> information during gimplification and use in later passes?
>>
>> By using it ;)  See how gimplification of COMPONENT_REF works
>> for example.  The offset becomes an explicit operand and its
>> computation get put into explicit statements.  There is no 'reverse-mapping'
>> to lookup or even re-construct this information at later time.
>>
> I think gimplification pass is too early for me to decide if I want to
> use all these offsets and sizes.
>
> Actually when I a look into GIMPLE dumps I see that all these values
> are computed and corresponding SSA_NAMEs exist in the code.
>
> I use the following source exapmle:
>
> int foo(int len)
> {
>   struct {
>     int a;
>     int buf[len];
>     int b;
>   } s;
>   return foo1(s.buf);
> }
>
> In GIMPLE I see a lot of values computed for all sizes, unit sizes and offsets:
>
>   saved_stack.2_1 = __builtin_stack_save ();
>   len.0_3 = len_2(D);
>   D.2241_4 = (bitsizetype) len.0_3;
>   D.2242_5 = D.2241_4 * 32;
>   D.2243_6 = (sizetype) len.0_3;
>   D.2244_7 = D.2243_6 * 4;
>   D.2245_8 = (long int) len.0_3;
>   D.2246_9 = D.2245_8 + -1;
>   D.2247_10 = (sizetype) D.2246_9;
>   D.2241_11 = (bitsizetype) len.0_3;
>   D.2242_12 = D.2241_11 * 32;
>   D.2243_13 = (sizetype) len.0_3;
>   D.2244_14 = D.2243_13 * 4;
>   D.2243_15 = (sizetype) len.0_3;
>   D.2248_16 = D.2243_15 + 1;
>   D.2249_17 = D.2248_16 * 4;
>   D.2243_18 = (sizetype) len.0_3;
>   D.2250_19 = D.2243_18 + 2;
>   D.2251_20 = D.2250_19 * 32;
>   D.2252_21 = D.2251_20;
> ...
>
> I suppose there is always a sinle SSA_NAME for such vars and therefore
> I may associate them, e.g. via default definition. The only problem
> them is to not kill them until the very end. Currenty all those unused
> SSA_NAMES are killed by early optimizations pass. But even on O0 now
> we have all values computed and available for use until expand but
> cannot access them.

But that's exactly the issue.  Nothing keeps them live if they are not used.
And there is no "back-mapping" between DECL_SIZE and the SSA name
holding it's value at a certain point in the program.

Richard.

> Ilya
>
>> Richard.
>>
>>> Ilya
>>>
>>>>
>>>> Richard.
>>>>
>>>>>
>>>>> Thanks,
>>>>> Ilya


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]