This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Zero/Sign extension elimination using value ranges

On 20/05/14 16:52, Jakub Jelinek wrote:
> On Tue, May 20, 2014 at 12:27:31PM +1000, Kugan wrote:
>> 1.  Handling NOP_EXPR or CONVERT_EXPR that are in the IL because they
>> are required for type correctness. We have two cases here:
>> A) Mode is smaller than word_mode. This is usually from where the
>> zero/sign extensions are showing up in final assembly.
>> For example :
>> int = (int) short
>> which usually expands to
>>  (set (reg:SI )
>>           (sext:SI (subreg:HI (reg:SI ))))
>> We can expand  this
>>  (set (reg:SI ) (((reg:SI ))))
>> If following is true:
>> 1. Value stored in RHS and LHS are of the same signedness
>> 2. Type can hold the value. i.e., In cases like char = (char) short, we
>> check that the value in short is representable char type. (i.e. look at
>> the value range in RHS SSA_NAME and see if that can be represented in
>> types of LHS without overflowing)
>> Subreg here is not a paradoxical subreg. We are removing the subreg and
>> zero/sign extend here.
>> I am assuming here that QI/HI registers are represented in SImode
>> (basically word_mode) with zero/sign extend is used as in
>> (zero_extend:SI (subreg:HI (reg:SI 117)).
> Wouldn't it be better to just set proper flags on the SUBREG based on value
> Then not only the optimizers could eliminate in zext/sext when possible, but
> all other optimizations could benefit from that.

Thanks for the comments. Here is an attempt (attached) that sets
SUBREG_PROMOTED_VAR_P based on value range into. Is this the good place
to do this ?


Attachment: p.txt
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]