Re: [PATCH] bitint, v2: Avoid rewriting large/huge _BitInt vars into SSA after bitint lowering [PR114278]

[Richard Biener <rguenther@suse.de>]

On Mon, 11 Mar 2024, Jakub Jelinek wrote:

> On Mon, Mar 11, 2024 at 11:31:51AM +0100, Richard Biener wrote:
> > On Mon, 11 Mar 2024, Jakub Jelinek wrote:
> > 
> > > On Sat, Mar 09, 2024 at 12:25:42PM +0100, Richard Biener wrote:
> > > > Ideally we?d clear TREE_ADDRESSABLE but set DECL_NOT_GIMPLE_REG,
> > > > I think the analysis where we check the base would be a more
> > > > appropriate place to enforce that.
> > > 
> > > So like this?
> > 
> > Hm, I was thinking of non_rewritable_lvalue_p/non_rewritable_mem_ref_base
> > though that requires duplicating, so I guess handling in maybe_optimize_var 
> > would work.
> 
> I was considering it, but it looked like a waste to me, using bitmap bits
> for something that is always the case, we don't want to rewrite any
> large/huge _BitInt to SSA form after the lowering, not just some of them.
> 
> > I do now wonder whether setting DECL_NOT_GIMPLE_REG_P in bitfield
> > lowering would prevail?
> 
> Guess I can certainly try to set DECL_NOT_GIMPLE_REG_P on the large/huge
> _BitInt PARM_DECLs/RESULT_DECLs during bitint lowering even when they are
> TREE_ADDRESSABLE at that point; the VAR_DECLs have array types of limbs and
> so shouldn't be a problem.

Hmm, looking I think we're going to clear DECL_NOT_GIMPLE_REG_P since
we still have is_gimple_reg_type.

> > (sorry for approving the earlier patch now, I was too quick and didn't
> > remember the discussion)
> 
> Sorry, already committed, I can revert or incrementally adjust.

No problem, I think both patches are OK, the 2nd maybe a bit better
for alias analysis.

Richard.