[llvm-dev] RFC: Absolute or "fixed address" symbols as immediate operands

[Chris Lattner via llvm-dev]

> On Oct 10, 2016, at 8:12 PM, Peter Collingbourne via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi all,
> 
> I wanted to summarise some discussion on llvm-commits [0,1] as an RFC, as I felt it demanded wider circulation.
> 
> Our support for references to absolute symbols is not very good. The symbol will be resolved accurately in non-PIC code, but suboptimally: the symbol reference cannot currently appear as the immediate operand of an instruction, and the code generator cannot make any assumptions about the value of the symbol (so for example, it could not use a R_X86_64_8 relocation if the value is known to be in the range 0..255).
> 
> In PIC mode, if the reference is not known to be DSO-local, the value is loaded from the GOT (or a synthetic GOT entry), which again means suboptimal code. If the reference is known to be DSO-local, the symbol will be referenced with a PC relative relocation and therefore cannot be resolved properly to an absolute value (c.f. https://reviews.llvm.org/D19844 <https://reviews.llvm.org/D19844>). The latter case in particular would seem to indicate that a representational change is required for correctness to distinguish references to absolute symbols from references to regular symbols.
> 
> The specific change I have in mind is to allow !range metadata on GlobalObjects. This would
> be similar to existing !range metadata, but it would apply to the "address" of the attached GlobalObject, rather than any value loaded from it. Its presence on a GlobalObject would also imply that the address of the GlobalObject is "fixed" at link time. Alongside !range we could potentially use other sources of information, such as the relocation model, code model and visibility, to identify "fixed" globals, although that can be done separately.

Ok, I think I understand the use-case.

> I have been experimenting with a number of approaches to representation in SDAG, and I have found one that seems to work best, and would be the least intrusive (unfortunately most approaches to this problem are somewhat intrusive).
> 
> Specifically, I want to:
> 1) move most of the body of ConstantSDNode to a new class, ConstantIntSDNode, which would derives from ConstantSDNode. ConstantSDNode would act as the base class for immediates-post-static-linking. Change most references to ConstantSDNode in C++ code to refer to ConstantIntSDNode. However, "imm" in tblgen code would continue to match ConstantSDNode.
> 2) introduce a new derived class of ConstantSDNode for references to globals with !range metadata, and teach SDAG to use this new derived class for fixed address references

ConstantSDNode is poorly named, and renaming it to ConstantIntSDNode is probably the right thing to do independently of the other changes.

That said, I don’t understand why you’d keep ConstantSDNode around and introduce a new derived class of it.  This seems like something that a new “imm" immediate matcher would handle: it would match constants in a certain range, or a GlobalAddressSDNode known-to-be-small.  

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161010/0df32e59/attachment.html>