This is the mail archive of the gcc-patches@gcc.gnu.org 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: [RFC,PATCH] combine: Don't simplify subregs of promoted types


Hi,

> It seems to me that if you fix the code to correctly record
> nonzero_bits and sign_bit_copies for return values, then the right
> thing will happen.  In fact, there is already code to do this, in
> check_conversions and record_promoted_value.  The comments suggest
> that it should fix this exact problem.  Why is that not helping?

record_promoted_value does only record something for unsigned promotions
which doesn't help in that example.  But also when using unsigned int the
example contains an extend operation.  Your are right, the comment on 
record_promoted_value promises to take care of subregs optimized away.
But it does this by recording the information in the reg_stat of the subreg
register - r45 in the following example.  Unfortunately that register is
thrown away as well without ever reading the information recorded
in reg_stat[45].last_set_nonzero_bits.

(insn 8 7 9 2 (set (reg:DI 45)
        (reg:DI 2 %r2)) 51 {*movdi_64} (insn_list:REG_DEP_TRUE 7 (nil))
    (expr_list:REG_DEAD (reg:DI 2 %r2)
        (nil)))

(insn 9 8 10 2 (set (reg:SI 43 [ D.1596 ])
        (subreg/s:SI (reg:DI 45) 4)) 55 {*movsi_zarch} (insn_list:REG_DEP_TRUE 8 (nil))
    (expr_list:REG_DEAD (reg:DI 45)
        (nil)))

(insn 10 9 14 2 (set (reg:DI 47 [ D.1596 ])
        (sign_extend:DI (reg:SI 43 [ D.1596 ]))) 113 {*extendsidi2} (insn_list:REG_DEP_TRUE 9 (nil))
    (expr_list:REG_DEAD (reg:SI 43 [ D.1596 ])
        (nil)))

I'm experimenting with a patch which introduces a combine_simplify_subreg 
function.  That function records the promotion information in reg_stat when a subreg
is optimized away.  This makes the ZERO_EXTEND to be removed in
expand_compound_operation.  I'm currently trying to enhance this in order to 
cover SIGN_EXTENDS as well using the sign_bit_copies field.  Does that sound like
a solution to you?

Bye,

-Andreas-


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