This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fold BIT_FIELD_REF of a reference
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 4 Apr 2013 13:48:33 +0200
- Subject: Re: Fold BIT_FIELD_REF of a reference
- References: <alpine dot DEB dot 2 dot 02 dot 1304031557490 dot 31329 at stedding dot saclay dot inria dot fr> <CAFiYyc2_k+HqV3DjaTmDdP6CY3kLWM2mV83sFEDKH4c73ctwxw at mail dot gmail dot com> <alpine dot DEB dot 2 dot 02 dot 1304032010010 dot 3905 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc1daZqKPgv7qx3Y9s8oAbhkwwSX6P0PnN_gMbOU651KPQ at mail dot gmail dot com> <alpine dot DEB dot 2 dot 02 dot 1304041023040 dot 3882 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc31KR+VYgAFixJGyO170zBAcEutV=Zm6hYVt34JyxKdRw at mail dot gmail dot com> <alpine dot DEB dot 2 dot 02 dot 1304041144160 dot 3882 at laptop-mg dot saclay dot inria dot fr>
On Thu, Apr 4, 2013 at 12:11 PM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Thu, 4 Apr 2013, Richard Biener wrote:
>
>> On Thu, Apr 4, 2013 at 10:53 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
>>>
>>> On Thu, 4 Apr 2013, Richard Biener wrote:
>>>
>>>>>>> + if ((handled_component_p (arg0) || TREE_CODE (arg0) ==
>>>>>>> MEM_REF)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> This check means the optimization is not performed for
>>>>>> BIT_FIELD_REF[a, *, CST] which I see no particularly good reason for.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Er, are you trying to get rid of all BIT_FIELD_REFs? Why would you want
>>>>> to
>>>>> replace them with a MEM_REF? I actually think my patch already replaces
>>>>> too
>>>>> many.
>>>>
>>>>
>>>>
>>>> Yes, when I filed the bug I was working on bitfield lowering and the
>>>> only
>>>> BIT_FIELD_REFs that would survive would be bitfield extracts from
>>>> registers.
>>>
>>>
>>>
>>> Can't a vector (not in memory) count as a register?
>>
>>
>> Sure. A vector not in memory is a register.
>
>
> So we need to have some test whether something is "a register" and not
> create a MEM_REF in that case.
Ah, of course. Easy on the gimple side - just check is_gimple_reg ().
>
>>>> Thus, BIT_FIELD_REFs on memory would be lowered as
>>>>
>>>> reg_2 = MEM[ ... ];
>>>> res_3 = BIT_FIELD_REF [reg_2, ...];
>>>>
>>>> with an appropriately aligned / bigger size memory MEM.
>>>>
>>>> As a first step I wanted to lower all BIT_FIELD_REFs that can be
>>>> expressed
>>>> directly as memory access (byte-aligned and byte-size) to regular memory
>>>> accesses.
>>>
>>>
>>>
>>> But the transformation on BIT_FIELD_REF[A,...] will take the address of A
>>> even if A is not something that is ok with having its address taken.
>>
>>
>> I'd like to see a case where this happens.
>
>
> In the vector lowering pass, op0 is a SSA_NAME:
>
> typedef double vec __attribute__((vector_size(64)));
> vec f(vec x){
> return x+x;
>
> }
>
>>> I am probably missing something. Looking in tree-flow-inline.c, for
>>> MEM_REF[a,...]:
>>>
>>>> case MEM_REF:
>>>> {
>>>> tree base = TREE_OPERAND (exp, 0);
>>>> if (valueize
>>>> && TREE_CODE (base) == SSA_NAME)
>>>> base = (*valueize) (base);
>>>
>>>
>>>
>>> valueize is 0.
>>>
>>>> /* Hand back the decl for MEM[&decl, off]. */
>>>> if (TREE_CODE (base) == ADDR_EXPR)
>>>
>>>
>>>
>>> not the case here.
>>>
>>>> {
>>>> if (!integer_zerop (TREE_OPERAND (exp, 1)))
>>>> {
>>>> double_int off = mem_ref_offset (exp);
>>>> gcc_assert (off.high == -1 || off.high == 0);
>>>> byte_offset += off.to_shwi ();
>>>> }
>>>> exp = TREE_OPERAND (base, 0);
>>>> }
>>>> goto done;
>>>
>>>
>>>
>>> it returns a, which afaiu is an address.
>>> For MEM_REF[&b] it does return b.
>>
>>
>> No, it returns 'exp' which is still MEM_REF[&b].
>
>
> (Actually, for MEM_REF[a] it returns the input unchanged, and for
> MEM_REF[&b] it returns b)
> Thanks! I had completely misread that.
>
> --
> Marc Glisse