[Bug target/84826] ICE in extract_insn, at recog.c:2304 on arm-linux-gnueabi

[sudi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84826

--- Comment #6 from sudi at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #4)
> > So I looked into this. Turns out the actual issue is that USE_RETURN_INSN
> > (FALSE) changes its value and becomes false after pass ce3.
> > 
> > According to what I can see, arm_r3_live_at_start_p() starts to return true
> > after ce3.
> 
> Right and I think that we can live that.
> 
> > My question is:
> > 1) Is there any easy way to avoid the false positives from
> > arm_r3_live_at_start_p()
> 
> I don't think so.
> 
> > 2) Why is r3 still live at IN of BB2 when there is no reaching definition of
> > it? I mean also there will never be any reaching definition at IN of BB2.
> 
> Because r3 is an argument register so it has got an artifical def on entry:
> 
> ;;  entry block defs 	 0 [r0] 1 [r1] 2 [r2] 3 [r3] 12 [ip] 13 [sp] 14 [lr]
> 

Oops I think I missed the artificial defs. Then the liveness makes sense. Out
of curiosity why are all the argument register defined? This function for
instance does not need 4 argument register.

> 
> IMO the issue is that arm_compute_static_chain_stack_bytes changes its value
> and this doesn't make sense since whether or not the static chain is pushed
> onto the stack is decided once for all at prologue time.  So the fix is
> probably to cache the value of the function in the machine_function
> structure and return this cached value after prologue/epilogue generation
> (e.g. epilogue_completed == 1).

Thanks I think this approach solves the problem. I am currently testing a patch
for this.