> Initial aim of the pass was to remove zero extentions redundant due to
> implicit zero extention in x64. But implementation actually uses
> generic approach and seems like a mini-combiner. Pass may combine two
> zero extends or combine zero extend with a constant as a special case
> but in other cases we just try to merge two instructions and then
> check we have corresponding template. It can be easily adopted to
> remove all redundant extensions. So, byte add in the example will be
> merged with zxero extend only if we have explicit template for it in
> machine model.
OK.
> In this particular test case combiner may also help because we have
> byte memory load and extend on combiner pass. But due to some reason
> it does not merge them. In combiner dump I see
>
> (insn 39 38 40 4 (set (reg/v:QI 81 [ xr ])
> (mem:QI (reg/v/f:DI 111 [ ImageInPtr ]) [0 MEM[base:
> ImageInPtr_29, offset: 0B]+0 S1 A8])) 1.c:9 66 {*movqi_internal}
> (nil))
>
> (insn 43 42 44 4 (parallel [
> (set (reg:SI 116 [ xr ])
> (zero_extend:SI (reg/v:QI 81 [ xr ])))
> (clobber (reg:CC 17 flags))
> ]) 1.c:11 121 {*zero_extendqisi2_movzbl_and}
> (expr_list:REG_DEAD (reg/v:QI 81 [ xr ])
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil))))
The pseudo-register (reg/v/f:DI 111) is changed between insn 39 and insn 43 so
can_combine_p returns 0.
--
Eric Botcazou
