On 2019-12-24 2:37 a.m., Richard Biener wrote:
> On December 23, 2019 6:30:31 PM GMT+01:00, Erick Ochoa
> <erick.oc...@theobroma-systems.com> wrote:
>> Hi,
>>
>> I am working on an LTO pass which drops unused fields on structs. On my
>> tests, I found that the gimple generated for `sizeof` is a constant.
>> For
>> example, for the following C code:
>>
>> ```
>> struct astruct_s { _Bool c; _Bool a; _Bool b; };
>> struct astruct_s astruct;
>>
>> int
>> main()
>> {
>> int size = sizeof(astruct);
>> return 0;
>> }
>> ```
>>
>> Produces the following gimple code:
>> ```
>> size_1 = 3;
>> _2 = 0;
>> <L0>:
>> return _2;
>> ```
>>
>> Is there a way to determine where the value assigned to size_1 is
>> obtained from? I would like to
>> 1. inspect sizeof statements
>> 2. determine whether the argument of sizeof is struct astruct_s
>> 3. substitute struct astruct_s with a modified version of struct
>> astruct_s which has field `a` removed.
>>
>> Therefore, at the end of this transformation we would have size_1 = 2;
>> Similary, I would like pointer arithmetic to be affected. For example:
>>
>> ```
>> struct astruct_s { _Bool c; _Bool a; _Bool b; };
>> struct astruct_s astruct;
>>
>> int
>> main()
>> {
>> _Bool *c = &astruct.c;
>> _Bool *b = &astruct.b;
>> ptrdiff_t d = b - c;
>> printf("%d\n", d);
>> }
>> ```
>>
>> Produces the following gimple code:
>> ```
>> c_3 = &astruct.c;
>> b_4 = &astruct.b;
>> d_5 = b_4 - c_3;
>> ```
>>
>> Running the code results in the value 2 being printed . After running
>> the transformation, the result should be 1.
>>
>> Can anyone point me in the right direction?
>
> I believe there is no convenient point in the compilation to do all of this
> in GCC.
>
> Note that users can very well write a literal 8 (substitute correct value)
> for a
> Sizeof expression. Likewise writing pointer subtraction in terms of integers
> is possible.
>
>> So far I have tried changing the TYPE_FIELDS to drop field a, but that
>> doesn't work and it is not general. I also have some code which
>> creates a copy of RECORD_TYPE tree and modifies the tree and creates a
>> new identifier for this modified RECORD_TYPE tree. However, I believe
>> this may still not produce the intended behaviour.
>>
>> Any help is appreciated. Thanks!
Hi Richard,
can you please clarify what do you mean by:
>
> You need to analyze and change all actual accesses since not all of them will
> necessarily use component refs refering to the FIELD_DECLs you change.
If we are not using component refs to access the fields, what else can be used?
Do you mean something like taking the address of a struct and adding an offset
to access a field?
Thanks!
>
> Richard.
>
>> -Erick
>
