On Wed, Apr 25, 2012 at 11:29 PM, Olivier Hainque <hain...@adacore.com> wrote: > Thanks for your feedback Richard, > > On Apr 25, 2012, at 16:16 , Richard Guenther wrote: >> I think much better would be to simply disallow any toplevel >> VIEW_CONVERT_EXPR of BLKmode, > >> Does that fix your problems, too? If so I prefer that. > > Hmm, I think that this would fix the particular testscase at > hand but not quite the underlying issue I was aiming at. > > The basic problem I am trying to address is SRA turning > VCE (<some access>) into VCE (<scalar>) where the replacement > <scalar> is of a different size than <some access>. > > The idea of locating the check in create_access is that > this is where the <access> size is computed. > > I'm pretty sure that excluding just on BLKmode for > TYPE(<access>) doesn't catch them all. > > In particular, I'm pretty sure that we can get component > refs of integral modes that access a smaller range of bits > than what the mode conveys. It is common with packing or > rep clauses in Ada.
Yeah, well - the tree verification code in tree-cfg.c is not enforcing any constraints here and the docs are not clear either. My view is that we don't want the size of the VIEW_CONVERT_EXPR differ from the size of its operand - you should use a BIT_FIELD_REF or a MEM_REF for that (yes, VIEW_CONVERT_EXPRs could be removed or treated as short-cut for a BIT_FIELD_REF that covers the whole object). > I'll see if I can come up with a case tomorrow. > > I'm actually also slightly confused by the processing of > VCE inputs in SRA, as VCE (<composite>) and VCE (<scalar>) > are not supposed to result in the same outcome for identical > bit size and patterns on big endian. But I might just still > be missing something here. Well, it's not clear to me either what the semantics of a VIEW_CONVERT_EXPR is when you apply it to memory and the result is not of the same size as the operand. Naively a VIEW_CONVERT_EXPR is *(T *)&op? Then a VIEW_CONVERT_EXPR <T, op> would be the same as MEM_REF <T, &op, (T' *)0> with the advantage that for the MEM_REF you can specify the alias set that is supposed to be in effect. Similar it would be the same as BIT_FIELD_REF <T, &op, sizeof (T) * BITS_PER_UNIT, 0>. Can you formally relate those three representations and tell me why VIEW_CONVERT_EXPR is useful (not only convenient because of less operands) to use on lvalues (thus memory, compared to registers or constants)? Thanks, Richard. > Olivier >
