Re: expand/recog/match question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

On Tue, Aug 27, 2013 at 9:28 AM, Ian Lance Taylor <iant@xxxxxxxxxx> wrote:
> On Tue, Aug 27, 2013 at 9:02 AM, Hendrik Greving
> <hendrik.greving.intel@xxxxxxxxx> 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@xxxxxxxxxx> wrote:
>>> On Mon, Aug 26, 2013 at 7:51 PM, Hendrik Greving
>>> <hendrik.greving.intel@xxxxxxxxx> 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




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux