>> are we absolutely sure this is the only problem we will have >> with precision != bitsize and it is confined to the backend? Yes.
>>I would >>not dare to make that call. How does DSE come in here at all as you >>keep mentioning it? I mentioned DSE is because: We have DSE issue before so we use ADJUST_PRECISION to make PRECISON != BITSIZE but we still to walk around this DSE issue: https://github.com/gcc-mirror/gcc/commit/247cacc9e381d666a492dfa4ed61b7b19e2d008f However, this fix patch fixed DSE issue which makes PRECISON != BITSIZE, then GCC will generate padding bits for it which we don't want it. juzhe.zh...@rivai.ai From: Robin Dapp Date: 2023-06-29 16:14 To: Robin Dapp via Gcc-patches; 钟居哲; Jeff Law; kito.cheng; kito.cheng; palmer; palmer; richard.sandiford CC: rdapp.gcc Subject: Re: [PATCH V3] RISC-V: Fix bug of pre-calculated const vector mask for VNx1BI, VNx2BI and VNx4BI I grep'ed a bit and found several more instances of the same pattern which would probably all have to be adjusted (frontend-related mostly but also in native_encode_rtx). Most likely they would all have to be adjusted? > Sorry, only realised later, but: if the precision can cover fewer > bytes than the bitsize, I suppose there ought to be some zero-byte > padding at the end as well. It looks like this problem, and also the padding, has been discussed before when the precision of VNx1BI etc. was first adjusted in the RISC-V backend? I didn't immediately get the padding, though. So if we e.g. have a VNx2BI constant {0, 1} what would we pad the resulting value "2" to? A full byte? Juzhe, are we absolutely sure this is the only problem we will have with precision != bitsize and it is confined to the backend? I would not dare to make that call. How does DSE come in here at all as you keep mentioning it? Regards Robin
