Re: expand/recog/match question

[Ian Lance Taylor <iant at google dot com>]

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