https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112447

--- Comment #20 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
This is the reason of this patch:

The whole analysis is correct.But we made a mistake on inserting vsetvls.

This is the story.

We have 2 types of global vsetvls insertion.
One is earliest fusion of each end of the block.
The other is LCM suggested edge vsetvls.

So before this patch, insertion as follows:

(insn 2817 2820 2818 361 (set (reg:SI 67 vtype)
        (unspec:SI [
                (const_int 8 [0x8])
                (const_int 7 [0x7])
                (const_int 1 [0x1]) repeated x2
            ] UNSPEC_VSETVL)) 1708 {vsetvl_vtype_change_only}
     (nil))
(insn 2818 2817 999 361 (set (reg:SI 67 vtype)
        (unspec:SI [
                (const_int 32 [0x20])
                (const_int 1 [0x1]) repeated x3
            ] UNSPEC_VSETVL)) 1708 {vsetvl_vtype_change_only}
     (nil))

After this patch:

(insn 2817 2820 2819 361 (set (reg:SI 67 vtype)
        (unspec:SI [
                (const_int 32 [0x20])
                (const_int 1 [0x1]) repeated x3
            ] UNSPEC_VSETVL)) 1708 {vsetvl_vtype_change_only}
     (nil))
(insn 2819 2817 999 361 (set (reg:SI 67 vtype)
        (unspec:SI [
                (const_int 8 [0x8])
                (const_int 7 [0x7])
                (const_int 1 [0x1]) repeated x2
            ] UNSPEC_VSETVL)) 1708 {vsetvl_vtype_change_only}
     (nil))

The original insertion order is incorrect.

We should first insert earliest fusion since it is the vsetvls information
already there which was seen by later LCM. We just delay the insertion.
So it should be come before the LCM suggested insertion.

Feel free to investigate it with comparing before and after the patch.
Then feel free to send patch with this fix after you understand the reasons.

Thanks.

Reply via email to