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


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.

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]