Re: (patch,rfc) s/gimple/gimple */

[Richard Biener <richard.guenther@gmail.com>]

On Fri, Sep 18, 2015 at 3:32 PM, Trevor Saunders <tbsaunde@tbsaunde.org> wrote:
> On Wed, Sep 16, 2015 at 03:11:14PM -0400, David Malcolm wrote:
>> On Wed, 2015-09-16 at 09:16 -0400, Trevor Saunders wrote:
>> > Hi,
>> >
>> > I gave changing from gimple to gimple * a shot last week.  It turned out
>> > to be not too hard.  As you might expect the patch is huge so its
>> > attached compressed.
>> >
>> > patch was bootstrapped + regtested on x86_64-linux-gnu, and run through
>> > config-list.mk.  However I needed to update it some for changes made
>> > while testing.  Do people want to make this change now?  If so I'll try
>> > and commit the patch over the weekend when less is changing.
>>
>>
>> FWIW there are some big changes in gcc/tree-vect-slp.c:vectorizable_load
>> that looks like unrelated whitespace changes, e.g. the following (and
>> there are some followup hunks).  Did something change underneath, or was
>> there a stray whitespace cleanup here?  (I skimmed through the patch,
>> and this was the only file I spotted where something looked wrong)
>
> yeah, it was a stray whitespace cleanup, but I reverted it.
>
> Given the few but only positive comments I've seen I'm planning to
> commit this over the weekend.

Thanks a lot!

If you are still in a refactoring mood then I have sth else here.  When
streamlining the gimple accessors I noticed the glaring const-correctness
issue in

/* Return a pointer to the LHS of assignment statement GS.  */

static inline tree *
gimple_assign_lhs_ptr (const gassign *gs)
{
  return const_cast<tree *> (&gs->op[0]);
}

and was thinking to either "fix" it by removing the 'const' or by
merging gimple_assign_lhs and gimple_assign_lhs_ptr into

static inline const tree&
gimple_assign_lhs (const gassign *);

static inline tree&
gimple_assign_lhs (gassign *);

thus forgo X() vs. X_ptr() by using const/non-const references
as return values.  It's a little cost on the simple accessor
(extra dereference in the caller) but a cleaner API.

It would also preserve constness of users of the _ptr variant
if they don't end up modifying the thing.

Did I mention I never liked the "_ptr" notion?

Richard.

> Trev
>