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.
