On Thu, Apr 4, 2013 at 12:11 PM, Marc Glisse <marc.gli...@inria.fr> wrote: > On Thu, 4 Apr 2013, Richard Biener wrote: > >> On Thu, Apr 4, 2013 at 10:53 AM, Marc Glisse <marc.gli...@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