expand/recog/match question

[Hendrik Greving]

Thank you!

On Tue, Aug 27, 2013 at 11:10 AM, Ian Lance Taylor <iant@google.com> wrote:
> On Tue, Aug 27, 2013 at 9:32 AM, Hendrik Greving
> <hendrik.greving.intel@gmail.com> wrote:
>> It does. But even if it wouldn't, since it is 'recog', wouldn't that
>> be reload's problem? Actually my problem is solved (I forgot to allow
>> 'const' in the corresponding predicate), but I am still curious, if my
>> machine would not allow this, it looks like the compiler needs this
>> move in either case? What would I do if the machine would not support
>> such a move? I actually thought that you would do that with a proper
>> constraint, making reload handle this. But from what you're saying, it
>> sounds more that you had to do something 'earlier' about this?
>
> (Please don't top-post.  Thanks.)
>
> The reload pass (which is being replaced by LRA, by the way) relies on
> being able to move values around, including symbol constants.  That's
> the base it starts from.  So on a processor that can't load a
> full-word immediate constant, you can't get away with pushing the
> problem off onto reload, because reload won't know what to do.
>
> What you have to do is write your mov expanders to explicitly split
> large constants, typically using HIGH and LO_SUM, have the expander
> emit multiple instructions, and have patterns to match those
> instructions.  Then reload/LRA can call the expander and have the
> right thing happen.
>
> Ian
>
>
>> On Tue, Aug 27, 2013 at 9:28 AM, Ian Lance Taylor <iant@google.com> wrote:
>>> On Tue, Aug 27, 2013 at 9:02 AM, Hendrik Greving
>>> <hendrik.greving.intel@gmail.com> wrote:
>>>> Would you say that basically you're supposed to support that in terms
>>>> of predicates so it 'passes' recog?
>>>
>>> (Please don't top-post.  Thanks.)
>>>
>>> Yes, assuming your processor supports loading a full word immediate
>>> into a register in a single instruction (e.g., x86 does support that,
>>> MIPS does not).
>>>
>>> Ian
>>>
>>>
>>>> On Mon, Aug 26, 2013 at 10:50 PM, Ian Lance Taylor <iant@google.com> wrote:
>>>>> On Mon, Aug 26, 2013 at 7:51 PM, Hendrik Greving
>>>>> <hendrik.greving.intel@gmail.com> wrote:
>>>>>>
>>>>>> GCC 4.8.1 generates a movsi like this when compiling newlib with my backend:
>>>>>>
>>>>>> gdb) call debug_rtx(operand0)
>>>>>> (reg:SI 356)
>>>>>> (gdb) call debug_rtx(operand1)
>>>>>> (const:SI (plus:SI (symbol_ref:SI ("_ctype_locale_buf") <var_decl
>>>>>> 0x2aaaab15d558 _ctype_locale_buf>)
>>>>>>         (const_int 32 [0x20])))
>>>>>>
>>>>>> Any idea why the compiler tries to store such a weird construct? Is it
>>>>>> weird actually, or normal? I am trying to figure out if I either
>>>>>> allowed too much at some point (predicates?) or too little (do I need
>>>>>> to handle this with instructions?)?
>>>>>
>>>>> This seems normal enough to me.  It's basically
>>>>>     move reg356, $_ctype_locale_buf+32
>>>>> Here _ctype_locale_buf+32 is an immediate value which is known at link
>>>>> time.
>>>>>
>>>>> You will get this kind of thing from code like
>>>>>     p = &_ctype_locale_buf[32];
>>>>> if _ctype_locale_buf is a char array.
>>>>>
>>>>> Ian