On Fri, Oct 5, 2012 at 2:36 PM, Ilya Enkovich <enkovich....@gmail.com> wrote:
> 2012/10/5 Richard Guenther <richard.guent...@gmail.com>:
>> On Fri, Oct 5, 2012 at 10:28 AM, Ilya Enkovich <enkovich....@gmail.com>
>> wrote:
>>> 2012/10/4 Richard Guenther <richard.guent...@gmail.com>:
>>>> On Wed, Oct 3, 2012 at 7:05 PM, Ilya Enkovich <enkovich....@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
