https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592
--- Comment #5 from Feng Wang <wangfeng at eswincomputing dot com> --- I found something interesting, these operations such as zero_extend,sign_extend,zero_extract,sign_extract will be considered as compound operation and will transform to the approriate shifts and AND operations(This proc is in expand_compound_operation). So if the sign_extend op generated earlier,it will be converted by expand_compound_operation again during the after pass such as combine pass. In the combine pass, it will perform the opposite operation as above.Through make_compound and make_extraction functions two shifts insns will combine into sign_extend or zero_extend if the pattern exist,and then judge the cost of it.It is profitable replacement only when the arch supports sign_extend and costs less than two shifts insns. So I think the first patch is enough, https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg303789.html it handles the introduction of subregs when compiling and processing 32-bit using a 64 bit compiler. The first patch process the below rtl. (set (reg:SI 137) (ashiftrt:SI (subreg:SI (ashift:DI (reg:DI 140) (const_int 24 [0x18])) 0) (const_int 24 [0x18]))) During extract_left_shift processing,it wants to get reg:DI 140,but now the extraction is failed due to the subreg is in the front of the ashift. So I think we just need jump the subreg is enough to ensure normal subsequent processing.
