[PATCH] D35479: [CodeGen][mips] Support `long_call/far/near` attributes

John McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Jul 19 15:23:35 PDT 2017


rjmccall added inline comments.


================
Comment at: include/clang/Basic/AttrDocs.td:1336
+if code compiled using ``-mlong-calls`` switch, it forces compiler to use
+the ``jal`` instruction to call the function.
+  }];
----------------
sdardis wrote:
> rjmccall wrote:
> > sdardis wrote:
> > > rjmccall wrote:
> > > > I suggest the following wording:
> > > > 
> > > > Clang supports the ``__attribute__((long_call))``, ``__attribute__((far))``, and
> > > > ``__attribute__((near))`` attributes on MIPS targets.  These attributes may only be
> > > > added to function declarations and change the code generated by the compiler when
> > > > directly calling the function.  The ``near`` attribute allows calls to the function to
> > > > be made using the ``jal`` instruction, which requires the function to be defined in the
> > > > same 256MB segment as the caller.  The ``long_call`` and ``far`` attributes are
> > > > synonyms and require the use of a different call sequence that works regardless of
> > > > the distance between the functions.
> > > > 
> > > > These attributes take priority over command line switches such as ``-mlong-calls``.
> > > > requires the function to be defined
> > > 
> > > I'd change the "defined" to be "located".
> > > 
> > > > in the same 256MB segment as the caller.
> > > 
> > > I'd change this to: "in the same naturally aligned 256MB segment as the caller."
> > > 
> > > This also needs a note saying that it has no effect for code compiled with -fpic.
> > Oh, yes, if these statements are true then it's absolutely important to include them.  I was going off of the raw ISA specification, since jal just takes a relative offset, but if the toolchain has more specific requirements then those are what should be documented.
> > 
> > This whole feature is strange to me; do MIPS linkers just never introduce things like branch islands and lazy-binding functions?
> > since jal just takes a relative offset,
> 
> jal doesn't take an offset, the instruction takes an 26-bit immediate  (called the instruction index) shifts it left 2 bits and combines it with the remaining upper bits of the address of the instruction in the delay slot of jal to form the new $pc--so it's possible to jump from the bottom of a 256MB segment to the top.
> 
> (My apologies for the long answer here, jal is one of the odder control transfer instruction for MIPS.)
> 
> > This whole feature is strange to me; do MIPS linkers just never introduce things like branch islands and lazy-binding functions?
> 
> This feature is orthogonal to lazy-binding functions. The usage of 'long-call' and 'near' is to support bare-metal / static relocation model environments where the caller and callee might be in different memory segments (e.g. KSEG0 and KSEG1) or have a custom memory layout for their program's sections.
> 
> To the best of my knowledge, the GNU linker for MIPS only inserts stub functions / branch islands when compiling static code that calls PIC code. 
Well, that's what I get for skimming the first search hit instead of taking the time to read the real documentation.  Thank you for the correction.

Oh, and of course that's why you can't really use JAL in PIC: the linker could statically resolve instruction indexes within the current image, but only if the image gets loaded at a base address that's a multiple of 256MB!  That's obviously too coarse-grained to be workable.

What an unfortunate instruction design.


Repository:
  rL LLVM

https://reviews.llvm.org/D35479





More information about the cfe-commits mailing list