This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug target/78255] [5/6/7 regression] Indirect sibling call causing wrong code generation for ARM


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

wilco at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilco at gcc dot gnu.org

--- Comment #5 from wilco at gcc dot gnu.org ---
(In reply to avieira from comment #4)
> OK so after some extra debugging and digging I found that the postreload
> pass is basically turning the direct sibcall into an indirect sibcall. It
> takes cost into consideration, but does this only looking at the operands of
> the call, i.e. the cost of a symbolref vs the cost of a register. It does
> not take into consideration that it is doing a call. This doesn't seem like
> a good idea to me.

Also it looks like various other targets may have the same issue as using one
instruction for direct and indirect tailcalls is common among RISC targets.

So this is another generic cost issue whether it isn't possible to return
correct costs.

> Apart from that, I am now looking into letting arm_get_frame_offsets
> recalculate the offsets and registers to push and pop past reload_completed.
> I am not convinced this is entirely safe yet...

Indeed, as long as leaf_function_p is used in backends recomputing won't work.
Also accidentally changing the elimination offsets after reload will cause
havoc...

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]