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?
Ilya
>
> Please try attached patch.
>
> Uros.
