On Mar 11, 2021, Richard Biener <richard.guent...@gmail.com> wrote: > I wonder what the effect of this switch is - it's documented as > affecting the call site (different call insn sequence by default), so > the best representation would be an attribute on actual call stmts
I don't think that would fulfill its purpose. My understanding is that the longcall attribute is intended to issue call sequences that assume the target of the call will be out of range for available PC-relative addressing modes in call instructions. It is also often the case that the callee address ends up in a contiguous address, rather than as multiple fragments of insns, which simplifies relocation processing. One use I'm familiar with is when different modules are known to be going to be linked separately, and dynamically loaded at disparate memory locations, so that PC-relative branches across modules won't do, and PLTs are not available. When building one module, you declare as requiring long call sequences any functions expected to be defined in other modules. Or you just use long calls throughout, taking a slight performance penalty out of intra-module call sequences, that could have used PC-relative calls. > I agree that a type attribute (it's a type attribute likely to also > affect indirect calls) is a bit awkward Indirect calls are pretty much long calls by definition, but I suppose the goal of retaining the long-call requests has to do with the possibility of sometimes resolving an indirect call back to a direct call. If it wasn't associated with the type, the information would be lost at the point of the function decay to pointer, but I gather if we succeed in resolving a pointer back to a unique declaration, we would be able to take a longcall annotation from that declaration. I'm probably missing something. > but it does look better than just a global flag. That possibility is not lost in the ARM implementation. What the ARM command-line flag does is change the default call sequence for that translation unit. It can still be overridden either way. What the PPC command-line flag does is to add the attribute to every single function decl's type. The representations are isomorphic, equivalent in terms of representation power, but the PPC attributes-all-over choice is wasteful memory-wise, and it sacrifices optimizations that throw their hands up when they find function type attributes. OTOH, it brings some simplification to the function type system. ARM's representation has 4 states (two attributes that can each be present or absent): one nonsensical (both short_ and long_call present), and one (both absent) mapping to either of the two others, depending on the default. On PPC, there are only two states: longcall present or absent, and AFAIK it offers no possibility of overriding a longcall default on a per-function basis, only globally for a translation unit, which sort of renders all the attributes it adds redundant. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Vim, Vi, Voltei pro Emacs -- GNUlius Caesar
