Re: [PATCH] expansion: Sign or zero extend on MEM_REF stores into SUBREG with SUBREG_PROMOTED_VAR_P [PR98190]

2020-12-10 Thread Eric Botcazou
> So like this instead (if it passes another bootstrap/regtest)? > > 2020-12-10 Jakub Jelinek > > PR middle-end/98190 > * expr.c (expand_assignment): If to_rtx is a promoted SUBREG, > ensure sign or zero extension either through use of store_expr > or by extending

Re: [PATCH] expansion: Sign or zero extend on MEM_REF stores into SUBREG with SUBREG_PROMOTED_VAR_P [PR98190]

2020-12-10 Thread Jakub Jelinek via Gcc-patches
On Thu, Dec 10, 2020 at 11:15:30AM +0100, Eric Botcazou wrote: > Are you sure that the optimization is worth the hassle (and maybe the risk, > i.e. can't store_field clobber the entire field)? I'm not sure, after all, only the testcases I've mentioned were affected in the whole

Re: [PATCH] expansion: Sign or zero extend on MEM_REF stores into SUBREG with SUBREG_PROMOTED_VAR_P [PR98190]

2020-12-10 Thread Eric Botcazou
> 2020-12-10 Jakub Jelinek > > PR middle-end/98190 > * expr.c (expand_assignment): If to_rtx is a promoted SUBREG, > ensure sign or zero extension when the most significant bit has > been overwritten, either through use of store_expr or by extending > manually. >

[PATCH] expansion: Sign or zero extend on MEM_REF stores into SUBREG with SUBREG_PROMOTED_VAR_P [PR98190]

2020-12-10 Thread Jakub Jelinek via Gcc-patches
Hi! Some target decide to promote certain scalar variables to wider mode, so their DECL_RTL is a SUBREG with SUBREG_PROMOTED_VAR_P. When storing to such vars, store_expr takes care of sign or zero extending, but if we store e.g. through MEM_REF into them, no sign or zero extension happens and