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.
Ilya
> Richard.
>
>> Ilya
>>
>>>
>>> Richard.
>>>
>>>>
>>>> Thanks,
>>>> Ilya
