Hi!
On aarch64 the backend decides to use non-BLKmode for some arrays
like unsigned long[4] - OImode in that case, but the corresponding
BITINT_TYPEs have BLKmode (like structures containing that many limb
elements). This both isn't a good idea (we really want such underlying vars
to live in memo
On Thu, 18 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> On aarch64 the backend decides to use non-BLKmode for some arrays
> like unsigned long[4] - OImode in that case, but the corresponding
> BITINT_TYPEs have BLKmode (like structures containing that many limb
> elements). This both isn't a good id
On Thu, Jan 18, 2024 at 08:27:51AM +0100, Richard Biener wrote:
> On Thu, 18 Jan 2024, Jakub Jelinek wrote:
>
> > Hi!
> >
> > On aarch64 the backend decides to use non-BLKmode for some arrays
> > like unsigned long[4] - OImode in that case, but the corresponding
> > BITINT_TYPEs have BLKmode (lik
And
--- gcc/expr.cc.jj 2024-01-12 10:07:58.194851657 +0100
+++ gcc/expr.cc 2024-01-18 12:08:16.412147569 +0100
@@ -12382,6 +12382,21 @@ expand_expr_real_1 (tree exp, rtx target
}
}
+ /* Ensure non-BLKmode array VAR_DECLs VCEd to BLKmode BITINT_TYPE
+aren't promo
On Thu, 18 Jan 2024, Jakub Jelinek wrote:
> On Thu, Jan 18, 2024 at 08:27:51AM +0100, Richard Biener wrote:
> > On Thu, 18 Jan 2024, Jakub Jelinek wrote:
> >
> > > Hi!
> > >
> > > On aarch64 the backend decides to use non-BLKmode for some arrays
> > > like unsigned long[4] - OImode in that case,
On Thu, Jan 18, 2024 at 01:16:45PM +0100, Richard Biener wrote:
> > This doesn't actually do anything, because the base is TREE_ADDRESSABLE.
> > The var gets both with -O0 and -O2 DECL_RTL like
> > (mem/c:OI (plus:DI (reg/f:DI 95 virtual-stack-vars)
> > (const_int -64 [0xf
On Thu, 18 Jan 2024, Jakub Jelinek wrote:
> On Thu, Jan 18, 2024 at 01:16:45PM +0100, Richard Biener wrote:
> > > This doesn't actually do anything, because the base is TREE_ADDRESSABLE.
> > > The var gets both with -O0 and -O2 DECL_RTL like
> > > (mem/c:OI (plus:DI (reg/f:DI 95 virtual-st
On Thu, Jan 18, 2024 at 01:34:53PM +0100, Richard Biener wrote:
> So - if we simply do
>
> /* If the input and output modes are both the same, we are done. */
> if (mode == GET_MODE (op0) || (mode == BLKmode && MEM_P (op0))
> ;
>
> ? After all if we want BLKmode we want a ME
On Thu, 18 Jan 2024, Jakub Jelinek wrote:
> On Thu, Jan 18, 2024 at 01:34:53PM +0100, Richard Biener wrote:
> > So - if we simply do
> >
> > /* If the input and output modes are both the same, we are done. */
> > if (mode == GET_MODE (op0) || (mode == BLKmode && MEM_P (op0))
> >
On Thu, Jan 18, 2024 at 01:57:49PM +0100, Richard Biener wrote:
> > - RTL expansion expectes TARGET_MEM_REF to always address actual
> > memory. */
> > + RTL expansion expectes TARGET_MEM_REF to always address actual memory.
> > + Also, force to stack non-BLKmode vars accessed through
On Thu, Jan 18, 2024 at 02:13:55PM +0100, Jakub Jelinek wrote:
> The == BITINT_TYPE check is non-essential, was just trying to keep existing
> behavior otherwise. I can certainly drop that.
So following then?
2024-01-18 Jakub Jelinek
Richard Biener
* cfgexpand.cc (disco
On Thu, 18 Jan 2024, Jakub Jelinek wrote:
> On Thu, Jan 18, 2024 at 02:13:55PM +0100, Jakub Jelinek wrote:
> > The == BITINT_TYPE check is non-essential, was just trying to keep existing
> > behavior otherwise. I can certainly drop that.
>
> So following then?
OK.
Thanks,
Richard.
> 2024-01-1
12 matches
Mail list logo
