public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ramana Radhakrishnan <ramana.radhakrishnan@linaro.org>
To: Carrot Wei <carrot@google.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, ARM] PR47855 Compute attr "length" for some thumb2 insns
Date: Thu, 31 Mar 2011 16:04:00 -0000	[thread overview]
Message-ID: <4D94A47C.5070305@linaro.org> (raw)
In-Reply-To: <BANLkTinTPqCQxPg+Ou5LWSSgtHuXgjyqGg@mail.gmail.com>



>> Hi Carrot,
>>
>>
>>         How about adding an alternative only enabled for T2 that uses the `l'
>> constraint and inventing new constraints for some of the constant values
>> that are valid for 16 bit instructions since the `I' and `L' constraints
>> have different meanings depending on whether TARGET_32BIT is valid or not ?
>> We could then set the value of the length attribute accordingly. I don't
>> think we can change the meaning of the I and L constraints very easily given
>> the amount of churn that might be needed
>>
> You are right. Now the logic is much clearer by splitting the constraints.

Sorry I wasn't too clear .

What I meant was to use the "enabled" trick and enable this only when 
Thumb2 is enabled in the compiler.

So what you could do instead is add the alternative and then use the 
arch attribute to enable this only for Thumb2.

i.e.

>>   (define_insn "*arm_cmpsi_insn"
>>     [(set (reg:CC CC_REGNUM)
>> -	(compare:CC (match_operand:SI 0 "s_register_operand" "r,r")
>> -		    (match_operand:SI 1 "arm_add_operand"    "rI,L")))]
>> +	(compare:CC (match_operand:SI 0 "s_register_operand" "l,r,r,r")
>> +		    (match_operand:SI 1 "arm_add_operand"    "Py,r,I,L")))]
>>     "TARGET_32BIT"
>>     "@
>>      cmp%?\\t%0, %1
>> +   cmp%?\\t%0, %1
>> +   cmp%?\\t%0, %1
>>      cmn%?\\t%0, #%n1"
>> -  [(set_attr "conds" "set")]
>> +  [(set_attr "conds" "set")

        (set_attr "arch" "t2, any")
        (set_attr "length" "2, 4")]

Does that look any better ? That way you can now safely add options on a 
per arch basis and reduce the amount of complexity for some of these 
length calculations.


>>
>>         I don't think this and the other conditional branch instruction
>> changes are correct. This could end up being the last instruction in an IT
>> block and will automatically end up getting the 32 bit encoding and end up
>> causing trouble with the length calculations. Remember the 16 bit encoding
>> for the conditional instruction can't be used as the last instruction in an
>> IT block.
>>
> According to arm architecture reference manual, chapter A8.6.16, neither 16 bit
> nor 32 bit conditional branch can be used in IT block. Only unconditional branch
> can be used as the last instruction in IT block, and it isn't related
> to instruction
> length. So we don't need to care about branch instruction encoding in IT block.

Yes I think you are right in this case. The reason I think I 
misinterpreted this was ofcourse the fact that conditional branches as 
the last instruction in the ARM-ARM. I don't know why I misread it last 
night.


cheers
Ramana

  reply	other threads:[~2011-03-31 15:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-26 15:55 Carrot Wei
2011-03-30  1:24 ` Ramana Radhakrishnan
2011-03-30  7:35   ` Chung-Lin Tang
2011-03-30 12:41     ` Richard Earnshaw
2011-03-31  3:34   ` Carrot Wei
2011-03-31 16:04     ` Ramana Radhakrishnan [this message]
2011-04-01  6:57       ` Carrot Wei
2011-04-05 13:32         ` Ramana Radhakrishnan
2011-04-06  2:26           ` Carrot Wei
2011-04-07  9:32         ` Richard Sandiford
2011-04-07 11:09           ` Carrot Wei
2011-04-07 11:31             ` Ramana Radhakrishnan
2011-04-08  7:36               ` Carrot Wei
2011-04-08  8:36                 ` Ramana Radhakrishnan
2011-04-08  8:52                   ` Carrot Wei
2011-04-08  9:01                     ` Ramana Radhakrishnan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D94A47C.5070305@linaro.org \
    --to=ramana.radhakrishnan@linaro.org \
    --cc=carrot@google.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).