Richard Biener <richard.guent...@gmail.com> writes: > On Fri, Nov 15, 2019 at 11:02 AM Richard Sandiford > <richard.sandif...@arm.com> wrote: >> >> The new tree-cfg.c checking in r278245 tripped on folds of >> ALTIVEC_BUILTIN_VPERM_*, which were using gimple_convert >> rather than VIEW_CONVERT_EXPR to reinterpret the contents >> of a vector as a different type. >> >> Spot-tested on powerpc64-linux-gnu. OK to install? > > Hmm, I think we should fix this up in gimple_convert instead.
I think that's going to lead to too much overloading of what "convert" means though. E.g. for V2HI->V2SI it's now a sign or zero extension, just like for HI->SI. Whereas V4HI->V2SI would pack two HIs into a single SI. If gimple_convert is going to be "helpful", there's the question of what it should do for something like SI->SF. Should it be a FLOAT_EXPR or a VIEW_CONVERT_EXPR? If gimple_convert of V4SI->V4SF acts like a VIEW_CONVERT_EXPR then it seems more consistent for SI->SF to do the same, which IMO would be surprising for a function called gimple_convert. (I always forget that FLOAT_EXPR has its own code and expect "convert" to mean what it does in C.) Whereas if SI->SF is a FLOAT_EXPR than presumably V4SI->V4SF should be too. So IMO it's good that callers are explicit about what they actually want, with gimple_convert having the same semantics as CONVERT_EXPR/NOP_EXPR. Thanks, Richard
