On Fri, Nov 15, 2019 at 11:59 AM Richard Sandiford <richard.sandif...@arm.com> wrote: > > 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.
Hmm, indeed. > 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. OK, I wonder how I got away with gimple_convert in epilogue generation but I guess I'm only ever doing sign conversions there and we seem to accept both NOP and VCE for that. Richard. > Thanks, > Richard
