Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> writes: > On Mon, 4 Oct 2021, Qing Zhao wrote: > >> >> >> > On Oct 4, 2021, at 12:19 PM, Richard Biener <rguent...@suse.de> wrote: >> > >> > On October 4, 2021 7:00:10 PM GMT+02:00, Qing Zhao <qing.z...@oracle.com> >> > wrote: >> >> I have several questions on this fix: >> >> >> >> 1. This fix avoided expanding “.DEFERRED_INIT” when !tree_fits_uhwi_p >> >> (TYPE_SIZE_UNIT (var_type)). >> >> As a result, this call to .DEFERRED_INIT will NOT be expanded at all. >> > >> > Yes. >> >> Then, should we exclude such auto init during gimplification phase? > > No, we do want to and can handle such variables just fine. > >> > >> >> Then not expanding .DEFERRED_INIT in RTL expanding phase will trigger >> >> more issues in later RTL phases, this looks not correct to me. (Actually, >> >> with is the patch, this testing case still failed in a later RTL stage). >> >> >> >> So, If we really want to avoid auto-init for VLA vectors, we should not >> >> add call to .DEFERRED_INIT in gimplification phase at all. >> >> >> >> >> >> >> >> 2. For the added .DEFERRED_INIT: >> >> >> >> __SVFloat64_t f64; >> >> >> >> f64 = .DEFERRED_INIT (POLY_INT_CST [16, 16], 2, 0); >> >> >> >> What does “POLY_INT_CST[16,16]” mean? Is this a constant size? If YES, >> >> what’s the value of it? If Not, can we use “memset” to expand it? >> > >> > When the target is a register memset doesn't work. I'm not sure the memset >> > expansion path will work as-is either for aggregates with vla parts - >> >> Stupid question here: what does POLY_INT_CST[16,16] mean? It’s not a >> constant? > > It's 16 * <vector-factor> where the factor is determined by the hardware > implementation but fixed throughout the programs lifetime. You could > think of the POLY_INT_CST expanding to a multiplication of 16 by a special > hardware register. > > For vector types the zero-init could be done using build_zero_cst and > the expand_assignment path. Also the memset path should just work > as well. > > It's the pattern init that's a bit more complicated but I'm sure > Richard will sort that out. > > Note TYPE_SIZE_UNIT will honor tree_fits_poly_uint64_p but for the > pattern init we'd have to repeat the constant and maybe there's > a clever way to do this repeating just the single pattern byte. > > But as said... > >> > but I'll leave that to Richard S. to sort out. > > ^^^
Yeah, I'm hoping to get to this in stage 3 :-) The PR is still open until then and I agree the bypass is a good idea in the meantime. Thanks, Richard
