This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Do not drom MEM_EXPR when accessing structure fields
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, Jeff Law <law at redhat dot com>, Richard Biener <rguenther at suse dot de>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "rth at redhat dot com" <rth at redhat dot com>
- Date: Sun, 18 Sep 2016 21:30:04 +0200
- Subject: Re: Do not drom MEM_EXPR when accessing structure fields
- Authentication-results: sourceware.org; auth=none
- References: <AM4PR0701MB2162BC1DE149059CFEAB1E86E4F50@AM4PR0701MB2162.eurprd07.prod.outlook.com>
> Hi,
>
> > when expanding code for
> > struct a {short a,b,c,d;} *a;
> > a->c;
> >
> > we first produce correct BLKmode MEM rtx representing the whole
> > structure *a,
> > then we use adjust_address to turn it into HImode MEM and finally
> > extract_bitfield is used to offset it by 32 bits to get correct value.
>
> I tried to create a test case as follows and stepped thru the code.
>
> cat test.c
> struct a {short a,b,c,d;};
> void foo (struct a *a)
> {
> a->c = 1;
> }
>
>
> First I get a DImode MEM rtx not BLKmode:
>
> (mem:DI (reg/f:DI 87) [2 *a_2(D)+0 S8 A16])
>
> and adjust_address does not clear the MEM_EXPR
>
> thus to_rtx = adjust_address (to_rtx, mode1, 0) returns:
>
>
> (mem:HI (reg/f:DI 87) [2 *a_2(D)+0 S2 A16])
>
> and then set_mem_attributes_minus_bitpos (to_rtx, to, 0, bitpos) does:
>
> (mem:HI (reg/f:DI 87) [3 a_2(D)->c+-4 S6 A16])
>
> which looks perfectly OK.
>
> But with your patch the RTX looks different:
>
> (mem:DI (reg/f:DI 87) [3 a_2(D)->c+-4 S6 A16])
>
> which looks inconsistent, and not like an improvement.
Hmm,
the memory reference does point to a_2(D)->c+-4 so I would say it is OK. The
memory refernece is not adjusted yet to be reg87+4 and this is where memory
attributes got lost for me (because the pointer becames out of range of (mem:HI
(reg87))). I see this does not happen on x86_64, I will try to see why
tomorrow.
Honza