On Wed, Nov 20, 2013 at 5:33 PM, Ilya Enkovich <enkovich....@gmail.com> wrote: >>> CM_MEDIUM has unlimited data size. >>> >>> i386-opts.h: CM_MEDIUM, /* Assumes code fits in the low 31 >>> bits; data unlimited. */ >>> >>> The x86_64_zext_immediate_operand allows _address_ to be loaded by >>> movl. The @SIZE reloc returns object size, which is unlimited and has >>> no connection to its address. For CM_MEDIUM, >>> x86_64_zext_immediate_operand allows: >>> >>> return (ix86_cmodel == CM_SMALL >>> || (ix86_cmodel == CM_MEDIUM >>> && !SYMBOL_REF_FAR_ADDR_P (op))); >> >> Yes, but large symbols never have SYMBOL_FLAG_FAR_ADDR set. > > Sorry, I mean all large symbols have this flag set.
This flag marks the fact that object size is bigger than -mlarge-data-threshold and goes into large section. It is true that UInt option argument currently overflows at 4G, and consequently all sizes larger than 4G go to large sections, but IMO, we should not rely on this. The specification says unlimited data size, so we have to be prepared for this. The reason I am against checking "Z" constraint is that "@SIZE" relocation returns _size_ of the object (which is only remotely connected to its address), while "Z" checks the address of the object. So, it looks to me that this check would be conceptually wrong. The right place to "fix" movabs is in a linker relaxation pass that can check the real size and change movabs to movl if the size fits 32bits. As a side note, perhaps generic option subsystem should reject overflows as e.g. -mlarge-data-threshold=5368709120 when 32bit UInt is used for option argument. The effects of overflow are surprising. Uros.