2013/11/20 Uros Bizjak <ubiz...@gmail.com>:
> On Wed, Nov 20, 2013 at 5:11 PM, Ilya Enkovich <enkovich....@gmail.com> wrote:
>> 2013/11/20 Uros Bizjak <ubiz...@gmail.com>:
>>> On Wed, Nov 20, 2013 at 1:32 PM, Ilya Enkovich <enkovich....@gmail.com>
>>> wrote:
>>>
>>>>> >> > Here is a patch to add size relocation and instruction to obtain
>>>>> >> > object's size in i386 target.
>>>>> >>
>>>>> >> +(define_insn "move_size_reloc_<mode>"
>>>>> >> + [(set (match_operand:SWI48 0 "register_operand" "=r")
>>>>> >> + (match_operand:<MODE> 1 "size_relocation" "Z"))]
>>>>> >> + ""
>>>>> >> +{
>>>>> >> + return "mov{<imodesuffix>}\t{%1, %0|%0, %1}";
>>>>> >>
>>>>> >> Please don't change x86_64_immediate_operand just to use "Z"
>>>>> >> constraint The predicate is used in a couple of other places that for
>>>>> >> sure don't accept your change.
>>>>> >>
>>>>> >> Better write this insn in an explicit way (see for example
>>>>> >> tls_initial_exec_64_sun). Something like:
>>>>> >>
>>>>> >> (define_insn "move_size_reloc_<mode>"
>>>>> >> [(set (match_operand:SWI48 0 "register_operand" "=r")
>>>>> >> (unspec:SWI48
>>>>> >> [(match_operand 1 "symbolic_operand" "..." )]
>>>>> >> UNSPEC_SIZEOF))]
>>>>> >> ""
>>>>> >> "mov{<imodesuffix>}\t{%a1@SIZE, %0|%0, %a1@SIZE}")
>>>>> >>
>>>>> >> You will probably need to define new operand 1 predicate and
>>>>> >> constraint.
>>>>> >>
>>>>> >> Uros.
>>>>> >
>>>>> > Hi, Uros! Thanks for comments! Here is what I got trying to follow
>>>>> > your suggestion. Does it look better?
>>>>>
>>>>> You actually don't need any operand modifiers in the insn template.
>>>>> Simply use:
>>>>>
>>>>> "mov{<imodesuffix>}\t{%1@SIZE, %0|%0, %1@SIZE}"
>>>>>
>>>>> and you will automatically get
>>>>>
>>>>> "movl $zzz, %eax" or "mov %eax, OFFSET FLAT: zzz".
>>>>>
>>>>> Since your pattern allows only symbolic_operand, there is no reload,
>>>>> so you can avoid the constraint alltogether.
>>>>>
>>>>> BTW: Did you consider various -mcmodel=... options? For DImode moves,
>>>>> you should check x86_64_zext_immediate_operand predicate and output
>>>>> either "movl $zzz, %eax" or "movabs $zzz, %rax". There is no movq with
>>>>> 64bit immediate. Please see movdi pattern.
>>>>
>>>> Yep, for large objects it may work wrongly. Does anyone use static objects
>>>> >4Gb? :)
>>>>
>>>> Large address does not mean large object but seems we have to be
>>>> conservative here. I added x86_64_zext_immediate_operand check with
>>>> additional CM_KERNEL check because in this model object size should always
>>>> fit 32 bits.
>>>
>>> IMO, we should list code models that support object sizes > 31bits for
>>> 64bit target. The object size in small models will never be > 31bits
>>> (and never negative), so we can use movl unconditionally.
>>
>> For medium models x86_64_zext_immediate_operand returns true for
>> object is known to go to lower 2Gb space. It should allow us to use
>> movl. Why do you always emit movabs for medium model?
>
> 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.
Ilya
>
> Uros.
