Thanks Robin for comments. > Hmm, yes, integer promotion would make sense. Then I guess the variables are > already in the optimized dump?
For uint16_t rs1 input, we have optimized dump similar as below unsigned int _6; vector([4,4]) unsigned int _27; _6 = (unsigned int) rs1_15(D); _27 = [vec_duplicate_expr] _6; Thus, I wonder if we can do something during expand, but in another PR. > It's not absolutely necessary to keep the same order in this case but it > helps > understanding. I would only change it if there's a combine opportunity or so. I see, let me update it in v2. Pan -----Original Message----- From: Robin Dapp <[email protected]> Sent: Tuesday, September 16, 2025 2:45 AM To: Li, Pan2 <[email protected]>; Robin Dapp <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected]; Chen, Ken <[email protected]>; Liu, Hongtao <[email protected]>; Robin Dapp <[email protected]> Subject: Re: [PATCH v1 1/4] RISC-V: Combine vec_duplicate + vwaddu.vv to vwaddu.vx on GR2VR cost >> Where does the actual HI->SI extension happen then? No chance we see it >> during combine/late-combine? > > There is no HI->SI extension from the 272.expand and combine dump, so there > is no change in RTL or > It is unsafe here. I think we need additional fix to make it work, may > related to int promotion I guess. Hmm, yes, integer promotion would make sense. Then I guess the variables are already in the optimized dump? > In theory yes, may be I am over-considering here. If it is equality, bring > the data > to vector first may be has better opportunities in rvv env. > It is totally to keep original sematics if it is useless or incorrect. It's not absolutely necessary to keep the same order in this case but it helps understanding. I would only change it if there's a combine opportunity or so.
